A FEW EXAMPLES OF BAD DATABASE DESIGN AND MANAGEMENT SO YOU CAN AVOID THEM

text that says database design. Designing and managing a database takes more than simply installing it — there are many moving parts and pieces, and if these aren’t managed properly, you could end up with a system that’s far less effective than it was meant to be. Here are a few common mistakes and tips on how to avoid them.

1) Lack of Naming Standards

A naming standard is a way of naming files (including those both provided to and generated by the database) in such a way as to avoid duplicates and be easily understood by anyone looking at them. Alas, many companies allow databases to create gibberish — or worse, results with the same names and different content.

Exactly what form your naming standards should take depends on the nature of the database and what you plan to do with it, but common things to include in names are the type of content the file contains, the date and time it was created, and a counter that notes how many files of that type have been made. Companies with a high number of files may do best if the counter is for a set period of time, such as a given day.

2) Poor Storage of Reference Data

Reference data should never be stored in multiple places or the code of an application — both of these are highly inefficient. Instead, the data should all be contained in a single centralized area that can be easily defined and accessed by software that needs to use it.

3) Lack of Documentation

Every database should have clear documentation of all its various components, including changes that are made at a later date. Unfortunately, many databases are built without this, so there’s no easy way to figure out the impact of changes or make sure a proposed change will function without breaking the rest of the system.

On the bright side, this is an easy problem to fix — all you need to do is ensure the database is fully documented during and after its creation. When people need to do something with it, they can pull out the documentation and get right to work, often saving time and money in the process.

4) Bad Choices for Primary Keys

A good primary key for a database meets three criteria.

  • Unchanging: Primary keys should not need to be changed. Ever.
  • Unique: Primary keys should never be duplicated between different users.
  • Reductionist: Primary keys should not be any longer or more complex than they really need to be.

Here at Ethany, we know how important it is to get a database built right the first time — in many cases, a bad database may well be worse than no database at all. If you suspect your company needs one — or you want to transfer from a bad system to a good one — contact our team today and ask for a consultation about your specific needs. We’ll help you figure out where to go from there.

Share This Posting