Pitfalls of Relational Database Design

As the saying has it, if the only tool you have is a hammer, every problem starts to look like a nail. Nothing could be truer with regard to the mistakes that people often make while trying their hands at database design.

Programmers with previous experience in nonrelational databases may tend to design databases that resemble hierarchical or network databases, or even flat files and spreadsheet designs, described in Chapter 1.

If you have the luxury of designing your database from scratch — consider yourself lucky and use every technique you can find in the database literature. More often you face the task of redesigning a database to fit new business requirements, improve performance, and so on. Whatever you do, never try reusing existing database structures as a basis for a new database. It is wrong for your particular task if it cannot accommodate the new features you are trying to implement. Take a fresh look without limits imposed by a previous design, already in place. If you seem to be able to re-use some parts and pieces, maybe there is no need for redesign. Maybe you need only to improve upon an existing database? Redesigning databases to preserve legacy data is not a small task and should be approached with caution.

Another common problem arises from the tendency to utilize every single feature offered by a particular RDBMS vendor. While improving performance — most of the time — this approach could lock you into that vendor's product; and it costs you dearly both in terms of time and money to move your database onto a different vendor. Believe it or not, there were times when dBASE, Btrieve, FoxPro, and Sybase were all the rage. Sticking to a few sound principles might not give you the very last drop of performance you could squeeze out of a database, but it would serve you well should you decide to go with a different RDBMS vendor down the road, or even to simply facilitate database maintenance tasks.

This short introduction to database design is clearly inadequate to turn you into a database design guru, but rather its purpose is to offer you help with your very first step on the road. We encourage you to look for more comprehensive books on the subject.