10 Database Design Best Practices

November 18, 2016 4:57 pm Published by


A database is no more than a mass of information stored in a framework that’s relatively easy to search. Everything else is detail. If your database works well, you can file away bits of related information automatically and pull out individual facts as needed. You should be able to discover new facts by comparing and compiling your data into reports and visualizations, and then store away those facts.

Within that simple definition, there is infinite variation. Before you define a single field on your next project, look over these 10 database design best practices that can dramatically simplify your life.

1. Consider Every Viewpoint During Planning

Don’t start building your database until you talk to the project sponsor and the users. Get agreements on precise expectations, and consider how much training the users will need for searching.

2. Decide Between SQL and NoSQL

Speed, scalability and fluid requirements are driving the growth of NoSQL databases. Web analytics, social networks and some other types of databases work much better as NoSQL framework. Make the decision as early as possible.

3. Normalize Your Data

In reality, most companies today are functioning in a hybrid world of SQL and NoSQL that work together in complex arrangements. No matter what, you still need to normalize your data to achieve minimum redundancy. Eliminate multi-valued attributes, eliminate repeated attributes, and then start in on the subkeys.

4. Make Structures Transparent

The database belongs to the future, not to you. Don’t use shortcuts, abbreviations or plurals. Use naming conventions. Don’t reinvent the wheel or make it difficult for those who may need to modify the database at some point, which will certainly happen.

5. Define Constraints to Maintain Data Integrity

Look into your range of options to enforce business rules, such as foreign keycheck, not null and the like. The application will prevent some bad data from getting in, but not all of it.

6. Document Everything

No matter how annoying it may seem, documentation is as essential as your primary keys. Take care to document your design, entity-relationship schemas and triggers.

7. Plan for Increasing Backup Time in the Build

Before you delve too deeply into the design, plan for failover clustering, auto backups, replication and any other procedures you need to ensure that the database structure remains intact during a natural or man-made disaster. Be ready immediately because the unexpected never waits for you.

8. Keep Privacy Primary

Encrypt passwords, and don’t give out the admin role without a deadline and well-documented reasons. This can be a tricky rule to follow due to office politics, but you should open up your database as little as possible. Vulnerabilities impact data integrity, which impacts everything else in the enterprise.

9. Optimize for Speed

Create indexes for queries that will be used regularly. Use a database analyzer to determine if an index or a clustered index is necessary.

10. Keep the Database on Its Own Server

Put the database on a different server than the web to lower CPU usage. In addition to freeing up compute resources, it also helps to keep the database out of the reach of unauthorized users.

Remember, database frameworks are not set in stone. You can refine and direct the workflow of your current database, or even break it up, when it make sense. Just as business goals and directives change over time, your database will probably need fine tuning.

Too often, administrators get stuck in thinking about how the database functions at the moment, without considering what it is capable of doing in the future. Instead of thinking, “it doesn’t work like that,” start from the viewpoint of “what is the end goal, and how can we get there?”

For more information, contact us today or visit our website.

Categorized in: , , ,