Chapter 6. Generalization: the key to a well-designed schema
The year: 2002. The project: approximately a year late and $1.5 million greater than budget. The team had grown from a small handful of developers to 19, but the work was getting further behind by the day. The project was mission critical to the organization, but because the organization’s culture valued friendship over performance, the delays were accepted. The situation had degraded to the point where management wanted a second opinion. I was told there were “no sacred cows—challenge everything.” (In hindsight, they should’ve known that was a challenge I’d relish).
The project collected data for monthly reporting—not a complicated project. Once I understood the requirements, I modeled the data using 17 tables. Yet the project’s database had 87 tables and would be easily characterized by most DBAs as “highly overnormalized.”
You’re reading this book, so I have no doubt that you, too, have run across databases that are proclaimed to be perfectly normalized yet are difficult to understand and query. Too many data modelers generate designs that are overly complex and painful to understand, query, or maintain. Why?
There’s a popular phrase: “Normalize until it hurts, then denormalize until it works.” Must normalization mean unwieldy? I don’t think so. I believe the problem is that normalization is only half of the design equation. The missing half is generalization.
