As I am starting the process of writing my next edition of the database design book (over the next 3+ years) I am starting to try to come up with some catchy way of stating that a database is well designed and implemented.  So I started to think of some metaphor and pillars is the best I could do. Catchy? Dunno, but the idea is that without one, the others could fail.

I figure I will post a blog on each of them first, and then work my way from there.  The end goal being a theme that I run through the book, starting in chapter one with a little intro, then relating the pillars through some of the book, but certainly culminating in the final chapter as a way to tie it all together.

The pillars I came up with are the following 7. The final number may be more or less, but eventually I need to figure a way to make the number have some deep meaning (7 is theologically, the perfect number!) but hey, who knows…I have a few years to ruminate on them.

Design

• Coherent – cohesive, comprehendible, standards based, names/datatypes all make sense, needs little documentation
• Normal – normalized as much as possible without harming usability/performance (based on testing)
• Fundamentally Sound – fundamental rules enforced such that you don’t have to check datatypes, base domains, relationships, etc
• Documented – Anything that cannot be gather from the previous four is written down and/or diagrammed for others

Implementation

• Secure – Users can only see data they are privy to
• Well Performing – Gives you answers fast
• Encapsulated – Changes to the structures cause only changes to usage where a table/column directly accessed it

I can see this being a great little set of things to have in the back of your mind when you are designing, sort of a checklist to see if you meet these different “pillars” of something or other.  Clearly it will take more work (and if any of you chimes in with ideas, I promise credit in the acknowledgements 🙂