What’s the point of that object

I can be a bit of a purist when it comes to design principals, but I think this is an important one.

Every object, schema, database etc. that you create should have a purpose, and that purpose should contain a What and a Why.

So, in my data warehouse designs I have a Staging database. It’s not enough to say “the staging database exists to hold staged data”, we have to say “the staging database exists to stage (extract, validate, apply transformation logic to) data from source systems so that we can present that staged data for the data warehouse to consume”. By keeping this purpose in mind whenever we make any changes to the database we make sure it is not filled with objects that are irrelevant to the purpose of the database, and by keeping the purpose simple we avoid having the database attempting to do too much.

We can apply this to schemas, and to tables, and stored procs and functions and pretty much everything else.

This provides additional benefits around documenting, unit testing, and other best practices you should be following with databases.