People are drawn to lists. Lists appear everywhere, from the Christian Bible to the weekly Top Forty countdown to the FBI’s most-wanted list to top ten lists on late night television (via David Letterman). Lists serve multiple helpful purposes: they help us to remember, impose order upon tasks, and provide guidance.
Some lists have taken on great importance in the world and in our lives. The Bill of Rights is such a list. So is the Ten Commandments. With this in mind, I began thinking about database systems, as I often do. And although we use lists to administer, program, and maintain our databases, there really is no overarching list of “things you should (or should not) do” to ensure an effective, accurate, well-designed database.
So I decided to create the list of Ten Database Commandments. Why ten? Oh, tradition, I guess. The list may not be complete, after all I do not claim to be all knowing! But I think it can server as a good starting point for database development and administration. If you have additions, modifications, disagreements, or whatever, I’d be happy to hear from you.
So here, without further ado, is the list of Ten Database Commandments:
- Thou shalt always design databases from a logical data model. Database design is of paramount importance to the usability and longevity of any database. Improperly designed databases will cause all types of problems ranging from poor performance to data integrity violations. If you do not begin with a well thought out data model, your database will suffer.
- Thou shalt always document thy database design. A lack of documentation will make future modification difficult at best, impossible at worst. Be sure to document every design decision (both logical and physical) and every subsequent change.
- (There are many important aspects of database administration, but of them all,) data integrity shalt always remain the most important design criterion. If the data is not accurate it does not matter how fast you can access it. Data integrity and accuracy is always the most important goal of any database implementation.
- Thou shalt encrypt personal and sensitive information, both at rest and in transit. Today’s data governance and regulatory compliance requirements demand that sensitive data be encrypted and/or masked.
- Thou shalt implement appropriate security within thy database and between thy DBMS and thy operating systems. An insecure database system can result in unauthorized access, data theft, and fraud.
- Thou shalt always maintain the recoverability of thy databases with sufficient backups to meet the availability requirements of the business supported by the data. Without a proper backup and recovery plan a logical or physical failure can result in a long outage or worse, lost data.
- Thou shalt implement and document a consistent workflow process for database change that assures data integrity while minimizing downtime. As we all know, change is the only constant. So once your database is implemented, it is inevitable that changes will eventually be required. To ensure availability and the safety of your production data, any changes should be made in a controlled, documented, and recoverable manner.
- Thou shalt always consider transaction performance in thy database design. Databases are built to be accessed. If the database can not be efficiently accessed to achieve the business purpose for which it was designed, it is worthless. Every database design (and implementation) should be analyzed to ensure that it can be accessed and modified within required service levels and within the stated budget. If not, either the service level or the budget needs to be adjusted, but you never want to do that at the last minute.
- Application developers and DBAs shalt always work together to ensure efficient code is written to access thy databases. Collaboration is necessary between developers and administrators to achieve optimally designed database applications.
- Thou shalt not download thy database to thy laptop. Oversight and governance of production data demands appropriate rules are setup and adhered to regarding data duplication and movement.
By posting these commandments, and encouraging your co-workers to follow them, you can raise the awareness of good database design and development practices. And wouldn’t that be a good thing?
