Datasheet

4
Part I ✦ Laying the Foundation
This chapter sets a principle-based foundation for the book, which provides a solid reason
for each of the following chapters. However, the principle addresses some advanced
database concepts, so if you’re new to databases I recommend that you dive right in to
Chapter 3, “Exploring SQL Server Architecture,” and come back to the database concepts
chapters later.
Simplicity vs. Complexity
Underscoring the Information Architecture Principle and the other six data store objectives is
a design methodology I jokingly call the Mortgage-Driven Simplicity Method. While corporate
IT programmers might eventually be terminated if their projects repeatedly fail, the conse-
quences for an independent consultant are much more immediate, and the mortgage must be
paid.
As a database consultant, I tend to take on the riskiest database projects— those considered
disasters by the client (who had fired the previous consulting firm, or firms, for failure to
deliver). In every case, the client originally asks me to finish the last 10 percent, or to opti-
mize a project that didn’t quite meet the requirements. What I usually find is a hopeless
design.
The primary lesson I’ve learned from successfully turning around dozens of failed database
projects is that the number one reason why software projects fail is not incompetent pro-
grammers, but an overly complex design. They fail because the designers were unable, or
unwilling, to imagine an elegant solution. I’ve learned a few lessons from having to pay my
mortgage based solely on my ability to deliver databases that performed.
The Mortgage-Driven Simplicity Method states:
Fear complexity. Continue to collaboratively iterate the design until the design team
unanimously agrees that it’s the simplest solution possible that meets the requirements.
Complexity
Complexity breeds complexity, and complexity causes several problems. The most common
result of complexity is that the project will outright fail. While a complex design may appear
to be clever, it seldom meets the requirements. Complexity also makes the solution more diffi-
cult for developers to understand and implement, resulting in late projects.
Assuming the project is completed, complexity negatively affects every one of the other six
data store objectives (usability, data integrity, performance, availability, extensibility, secu-
rity). A complex design makes it more difficult to retrieve and update the correct data, which
affects both usability and data integrity. Additional components create extra work (additional
reads, joins, extra updates) and adds interdependent variables, making tuning more complex,
all of which reduce performance.
The complex design potentially creates additional points of failure; and when problems do
occur, the complexity obscures the source of the problem, making it difficult or impossible to
diagnose and fix, which drives up support costs and limits availability. Compared to a simpler
design, complex designs are extremely difficult to modify and adapt to changing require-
ments. Finally, a complex set of components makes it less likely that data will be correctly
secured.
There’s a reason why the thesaurus entry for the word “difficult” includes the word “complex.”
Note
05_542567 ch01.qxp 9/27/06 9:58 PM Page 4