10 Big Mistakes Developers Make with Databases
   By Mike Gunderloy

Databases have been around for a long time, yet developers are still making the same database mistakes that should have been renovated long ago. Here are the first five of the 10 biggest offenders and how to stop making them—now.

Mistake #1: Choosing the Wrong Database
Not all databases are created equal — which means before you do anything you have to pick the right one. There are three tiers of databases in the market these days:

• Desktop and embedded databases, which are suitable for smaller tasks.

• "Express" versions of the key competitors that are good up to a few gigabytes of data.

• The truly valiant databases like SQL Server, Oracle and DB2, that can manage just about anything.

Before you do anything else, you need to make some realistic estimates about the amount of data that you'll be storing and pick the appropriate product to do the storage.

Mistake #2: Choosing Too Many Databases
Some APIs have promoted the notion of database independence – the idea that you can write your application code in such a manner that you can access any database for data storage. When you're starting out with a new product, pick your storage engine and write to it. If your product is good, people will install the database you specify and you won't be wasting man-hours supporting emergency scenarios that you'll probably never need.

Mistake #3: You Don’t Know Your Data
Database design can't be done in a vacuum away from the business rules. It's critical that you get the input of the actual users of the data. They need to tell you exactly how big each column needs to be, what rules apply to it, what types of data it will hold, who can update it and so on. Without all this imperative information, you're setting yourself up for costly rework down the line.

Mistake #4: If You Know One Database, You Know Them All
There's a tendency to assume that any developer knows how to set up a database. This results in many databases being designed by people who have never even heard the term normalization, let alone developed any understanding of the various normal forms. Efficient database design is something you need to learn, not discover by trial and error. Get the training you need now and save yourself the headache later.

Mistake #5: Taking Your Normalization Knowledge to the Extreme
A little knowledge can be a dangerous thing. There are some well-meaning developers who insist on putting everything in lookup tables in their databases. You need to know the normalization rules, but you also need to develop the skill to know when to stop normalizing and when denormalization for performance actually makes sense.

To test your database knowledge and ensure your data hygiene, check out our Data Quality Tools Suite

Don’t want to wait for the next issue of the Data Quality Advisor?
Read the last five trends now in our Advisor Article Archive