Database design - 1

There are plenty of good books and websites on database design. A keyword search for "database design" is sure to return plenty of hits.

The unfortunate fact is that design is overlooked for many applications which decide they need a database to store their data. So most databases become little more than data repositories or glorified text files (with a SQL wrapper).
Mention the word constraint and most developers throw their hands in the air and think immediately of the "constraint violated" errors. Even dedicated database developers try to get out of using constraints. The excuses are varied, here are some examples:

1) Constraints are slow.
2) Constraint errors are database specific.
3) What is a constraint? (common response from free database land)
4) The application implements the business logic not the database.

Good database design is determining what tables are required and relationships between those tables are required to implement business rules.
eg. If you have a sales app, a simple database would have a sales table and customer table. It makes little business sense to have a sale without an customer. An enabled constraint would stop a user or application adding sales without customers.

The main reason developers try to code the business logic in the application is so the application can be database generic.
If a designer designs the business logic into the database, the database becomes application generic.
Making the database application generic does not mean that there is no need for a specific app. It means that the database can be accessed by more than one specific application.

There seems to be a flow from everything runs on the server, to everything runs on client, with the potential of grid and clustering, once again running most of the stuff on a server becomes the best idea from a performance and recoverable viewpoint.

From a DBA perspective, performance is determined by design. No amount of indexing or parameter changes, memory, disk etc will fix flawed application logic and poor database design.

More on the markers of good and poor design later

Have Fun