In the world of databases, "getting it right" is a phrase filled with ambiguity, for who can say what "right" truly is? Frankly, it's a lot easier to spot "bad" or "not right" database schemas than it is to confirm that a database schema is "right". While schema design is the foundation of a well-performing database, you are missing opportunities if schema design doesn't also take database performance, administration and backup/recovery into consideration.
If you haven't done your homework or researched the corporate mission and business requirements--if you don't understand the real-world database management processes that tie database design to performance tuning, administration and backup/recovery, then your database project is headed down the path to failure. Integrating the best schema design that you know how to do, along with best practices in, for example, performance management and properly tuned and deployed SQL code will go a very long way toward ensuring your database environment is functioning at optimal levels. It also ensures that your data architects, DBAs, database performance team and data center managers and even business intelligence and applications teams are aligned and working together efficiently
Database modeling and design is at the core of a healthy database management and performance foundation. Getting it right the first time will enhance the bottom line in a variety of ways. It will:
* Eliminate haphazard approaches to maintaining data.
* Minimize maintenance and upkeep of the database schema.
* Optimize data retrieval for graphs and reports.
* Ensure data accuracy and reliability.
* Support corporate goals and evolving business initiatives, allowing the company to respond more quickly and precisely to new business opportunities and competitive threats.
The Challenge: The "Right" Design
In the world of database design, "getting it right" is a phrase filled with ambiguity, for who can say what "right" truly is? "Right," when a legacy system was first created, might not be adequate in today's rapidly-moving, Internet-based world. To complicate matters, there might not be a way to make "wrong" work in such a way that it's effectively "right" for today's situation.
Frankly, it's a lot easier to spot "bad" or "wrong" database schemas than it is to confirm that a database is "right". "Right" means that the database is working fine, productivity is high, performance is optimal, the corporate mission is being supported, the organization has the flexibility and underlying foundation, as expressed in the database schema, to move in directions that it needs to move in. "Wrong" can mean everything from operational constraints that are inhibiting corporate growth and development to partial transactions being applied to the database. When I'm called in to investigate a "wrong" condition, I try to get a holistic view of the situation. While schema design is the foundation of a well-performing database, I would be missing opportunities if I didn't take database performance, administration and backup/recovery and disaster recovery schemes into consideration. Each project and situation is going to be a little different from anything that you've experienced before, so when starting on a new project, do your homework. Research the corporate goals, strategic business initiatives and underlying business requirements. Understand how database management processes tie the database design to performance tuning and administration and even backup and recovery. Integrate the best schema design that you can after researching current best practices in performance management; ensure that the deployed SQL code is properly tuned and have a plan to keep it maintained. This will go a very long way toward insuring that the database environment you're working with is functioning at an optimal level. In the process, try to ensure that the data architects, the DBAs and the data center managers are aligned and working together efficiently.
The Opportunity: Identifying Problems Where They Exist
Each of the following situations is an example of a condition that could have been avoided if the individuals involved with designing and implementing the database had done it right in the first place.
Bad Record Design Lives Forever
Bad record layouts have been with us since the dawn of computing. Records that contain too many fields about too many different aspects of the data, records that when fully populated are longer than the database block...