Appendix 1
Rules of Normalization

Relational database design isn’t arbitrary or mysterious. You can use a number of well-defined rules to design a data storage strategy that avoids redundancy and helps make your application mistake proof, like the poka-yoke ideas mentioned earlier in this book. You’ve probably heard other metaphors for the same idea, such as defensive design or fail early.

The rules of normalization aren’t complicated, but they are subtle. Developers often misunderstand how they work, perhaps because they expect the rules to be harder than they are.

Another possibility is that people are turned off by having to follow rules at all. Rules are the bête noire of developers who value newness, creativity, and innovation. Rules are, in a way, the opposite of freedom.

Software developers continually make trade-offs between simplicity and flexibility. You can make a lot of work for yourself by reinventing the wheel and developing custom data management software for every application. Or you can take advantage of existing knowledge and technology if you can conform to a relational design when you use a relational database.

The antipatterns in this book are described using their own merits (or faults) to avoid being too academic or theoretical. In this appendix, you’ll see that theory can also be practical.