In the previous Industry Insight, I looked at the role of the database in business and IT today, and the importance of keeping the database fine-tuned for optimal performance.
In this Industry Insight, I will look at the subject of database design in a little more detail, listing some of the most common errors DBAs make in database design: the five deadly sins.
1. Failure to design and plan properly. Failing to plan is planning to fail. People wouldn't build a house without a proper plan and architecture, so why would they dream of not planning and designing with care and detail? Without a proper plan and design, they simply will not be able to implement inevitable changes. And because the database resides at the heart of IT systems and touches everything, the rigour and discipline of a plan and design is needed to ensure the project does not get blown off course.
Failing to plan is planning to fail.
Michael de Andrade is MD of EnterpriseWorx.
2. Choosing the wrong model. The choice of database model will be determined by the purpose of the application that the database serves. If the database is going to be running against a transactional system, the relational model will be selected. If the database is going to run in an analytical environment, such as a data warehouse or online analytical process (OLAP), a dimensional model will be chosen. This presupposes that a company will have a separate analytical and transactional database, and indeed, this is the ideal way to go. But for companies that lack the capital or can't cost-justify two discreet databases, but still need analytical capabilities, the model will be a hybrid one.
3. Failure to apply solid naming conventions. In applying names, two things are needed: easily understandable names, and consistency. Both will help future DBAs, programmers and users navigate their way through the database, and they will prevent ambiguity and confusion. Easily understood names are better than complex ones, especially for future DBAs, end-users and developers who will be using the database. The more arcane the name chosen for a column, a table or an object, the less likely future folk are going to be able to understand what is being referenced.
4. Failure to document. This is not unique to the database world: software developers also often make themselves guilty of not documenting their applications. The documentation should be clear enough to show anyone in the future what the database is modelling. There should be clearly defined naming standards, and clear definitions of each aspect of the database - tables, columns, relationships and more. This documentation should not be contained in the database itself, but rather in a separate metadata repository so that it is secure, easily accessible down the years and as easily updateable.
5. Failure to test. Testing is all too often the first casualty of a project overrun. When the project team is close to or over deadline, it's a good bet that they will skimp on testing. And then, when functionality and performance problems inevitably manifest, it will be far harder to diagnose and repair. Testing needs to be done consistently and thoroughly: load testing, performance testing, user acceptance testing, and all of this integrated into the overall project plan.
The long haul
There's a well-known aphorism: begin as you aim to finish. This is all too true with database design, which delivers great benefits if the right disciplines are applied up-front.
Database design and implementation are at the very heart of any business/IT project, and any shortcuts taken today will result in heartbreak tomorrow.
It's not easy to insist on the application of these disciplines, especially when the meter is ticking and management wants to see results. But failure to follow these five steps will result in an inconsistent and error-ridden project.
And what is gained today in time saved will prove to be false economy, as it will manifest in errors, bugs and problems further down the road.
* Michael de Andrade is MD of EnterpriseWorx.
Share