Introduction
I wrote recently on the importance of elegance in database design (Art vs. Science). In More on Elegance in Database Design: Complexity, I wrote about balancing the amount of complexity in design. In this installment, I want to talk about design decisions.
Who’s Buried in Grant’s Tomb?
How many states exist for two-state logic? It sounds like a trick question, or one of those interview questions that make you think a lot. I assure you this is neither. It’s much worse; it’s engineering.
The answer is four:
- True (On or 1)
- False (Off or 0)
- Unknown (Don’t Know or ?)
- Ignored (Don’t Care or X)
True and False are obvious to anyone who’s ever used a bit column in a table. If a bit column is NULLable, it has a third state: Missing. I am not going to duck into all the things NULL means and doesn’t mean in this post. For the purposes of this discussion, let’s agree missing data can be either Unknown or Ignored.
You use the four states of two-state logic to simplifiy digital statements via Boolean Algebra. One tool for reducing (or simplifying) Boolean statements is a Karnaugh Map. I used these often in my earlier life as an engineer. They’re great for reducing the number of gates required to implement a function in a digital circuit.
There are two interesting things about designing a function using Karnaugh Maps and the rules of Boolean Algebra. First, classifying Unknown and Ignored inputs is very important. Second, a minimal number of seemingly unrelated inputs can usually be combined to produce the desired output.
Split Decisions…
For a while I taught electronics at ECPI in Richmond. Teaching is a rewarding experience for me. I think it’s because I enjoy learning so much. For me, it’s like passing on a cool book or article or song or some of Christy‘s excellent recipes. It’s awesome to watch people figure stuff out!
As a teacher, I can tell when students have reached certain milestones. One milestone in teaching technicians and engineers about digital circuit design comes when they recognize decisions made early in the design process have an impact on the remaining design. Early decisions “ripple” through the rest of the design, affecting the set of available options.
More important than this, early decisions eliminate (or constrain) available options.
Just Add Scale
Now this is all well and good when you’re designing a small little circuit or application or database.
Things change with scale.
What I’m describing is scalability, and it’s demonstrated in the “For Want of a Nail” proverb:
For want of a nail the shoe was lost.
For want of a shoe the horse was lost.
For want of a horse the rider was lost.
For want of a rider the battle was lost.
For want of a battle the kingdom was lost.
And all for the want of a horseshoe nail.
This is an example of the Theory of Constraints in action, which is (in my opinion) an application of physics – specifically, aspects of entropy – to business. (Whew, what a tangent!)
In sum, when you choose:
- To make a column a certain data type
- Not to use schemas (other than dbo)
- To use a Naming Convention
- To use a certain design methodology
You are choosing to limit the remaining available options.
Conclusion
This isn’t necessarily a bad thing. Good engineers (and application architects and database professionals) use these limitations and constraints to their maximum effectiveness.
In elegant design, limits are leveraged.
:{> Andy
Comments