People are drawn to lists. Lists appear everywhere, from the Bible to the weekly Top-40 countdown, to the FBI’s most-wanted list. Lists serve multiple helpful purposes; they help us 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 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’s really no overarching list of “things you should do” to ensure an effective, accurate, well-designed database.
So, I decided to create a list of 10 Database Commandments. Why 10? Oh, tradition, I guess. The list may not be complete; after all, I don’t claim to be all knowing! But I think it can serve 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, without further ado:
1. 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 don’t begin with a well-thought-out data model, your database will suffer.
2. 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.
3. There are many important aspects of database administration, but data integrity shalt always remain the most important design criterion. If the data isn’t accurate, it doesn’t matter how fast you can access it. Data integrity/accuracy is the most important goal of any database implementation.
4. 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.
5. 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.
6. 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.
7. 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’s 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.
8. Thou shalt always consider transaction performance in thy database design. Databases are built to be accessed. If the database can’t be efficiently accessed to achieve the business purpose for which it was designed, it’s worthless. Every database design (and implementation) should be analyzed to ensure 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.
9. 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.
10. Thou shalt not download thy database to thy laptop. Oversight and governance of production data demands appropriate rules are set up 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?