A high-performance database is no longer a nice-to-have; in a world of nanosecond decision-making, it`s a business necessity. Alan Raubenheimer, CEO of Embarcadero Technologies Africa, analyses the impact on the business of an under-performing database and suggests solutions.
Under-performing databases are to be found in all businesses and are accepted as part of technology life. But they aren`t acceptable: they not only inconvenience users; they also cost the business direct revenue in lost customers and lost business opportunities.
For instance, e-commerce databases that power globally used Web sites must complete user transactions and present information fast enough to prevent impatient customers from clicking to a competitor`s site.
Companies needing current information cannot wait for long, drawn-out processes that crunch numbers. Instead, they need databases that can quickly churn out the data necessary to compete in today`s economy.
How ironic, then, that database vendors constantly publish benchmark figures indicating to just what extent they outperform each other in a never-ending quest for theoretical superiority. It would seem, on the face of it, that the underlying technology is ideally suited to the task.
The quest for better performance is engaged every day by database professionals at large and small companies. To help improve performance, many turn to expert consultants and performances monitors that track down and assist in eliminating system bottlenecks. However, in the pursuit for better overall database performance, many professionals ignore perhaps the number one contributor to excellent database speed: the physical design.
Design is overlooked for two simple reasons:
* It is difficult to perform correctly; and
* It is time-consuming.
Designing a high-performance database is complex. It takes skill and experience to yield a design that runs as fast as possible. But experienced personnel are at a premium, so junior workers are called on to design and build a database.
Looking back
Logical data modellers were thrown out in the early 1990s when Case (computer-aided systems engineering) tools that promised the world cracked under the strain of increasing business workloads. Since many Case tools failed to deliver what they had promised, and because many stressed logical design as the necessary forerunner of a good system, the importance of logical design was discounted.
Corporations had endured enough projects that never got off the drawing board, and so RAD (rapid application development) became the accepted mode of development. The result was that logical design isn`t taken as seriously in overall system development as it should be.
The second reason quality designs are overlooked with regards to performance is that a lot of up-front time is needed to create a good design. And time isn`t what a lot of companies have these days.
The application lifecycle has never been shorter. Projects that took years to complete just five years ago are being thrown up in six months or less. To accomplish such a feat requires either superior personnel using state-of-the-art software tools or the elimination of necessary tasks from the application construction equation. Usually, one of the first to go is the database logical design phase. Instead of intelligently laying out the necessary components and objects of a database, the database structure is built in the development phase alongside the code base used to run the application. The result is a design that cannot succeed.
Instead of concentrating on good design, database professionals look to other methods to enhance performance. However, when they do, they risk missing the boat entirely and they can end up dazed and confused with a database that simply won`t perform.
Much of today`s mindset dismisses the idea that altering and improving a database`s physical design will yield the largest possible performance benefit. Part of the reason is that modifying the design of a database - especially one in production - is no easy task and often requires healthy amounts of off-hours work by the administrator. So instead, many take the quick-fix approach: throwing hardware at the situation: an upgrade, more processors or more RAM.
In the short-term, things appear to improve, and if the database is static, there are no problems. But if it is dynamic and the data/user load continues to grow, the situation will soon regress.
The reason for this is simple: if the foundation is flawed, the house needs to be put in order at that level before anything else is done.
What about the link between availability and design? According to Oracle`s own studies of client downtime, the bulk, up to 36%, are design-related issues. That`s a wake-up call to get serious about design.
Make an impact in your database
How do you make a noticeable difference in the physical designs of the databases under your care? The first step is a mental one: making the commitment to pay more attention to excellent physical design. This includes all project management personnel.
The next step involves education on the part of the database designer.
You will also need to arm yourself with power tools that can slice through the difficulties involved in building and retrofitting complex designs. Long gone are the days when a DBA or modeller could handle most of their work with an SQL query interface and a drawing tool. Today, relational databases are too robust and complex for such primitive aids.
You will need two things as a minimum: a serious data modelling tool and a robust performance-monitoring product. Performance monitoring is the validation of a database`s physical design. When foundational cracks are identified with the monitor, you will need a high-quality design tool to aid in rectifying the situation.
DBAs who do not like to use data modelling tools will need two other software products: a feature-rich database administration tool and a change control product. The database administration tool will be used to create new objects for a database and to modify properties of existing objects. This tool is normally used in an add hoc manner and is great for graphically redesigning a database in real-time.
The change control product is a different animal. If you will not use a data modelling tool to capture and version control the designs of your databases, then you will need another method for protecting designs that are in place and working. Having such "snapshot backups" of your database`s schemas will prove invaluable when disaster strikes.
A change control tool can also help you in your physical design iterations. By periodically capturing changes you make to the physical design of your database, you can learn what worked and what didn`t. And if you make an "oops" and actually cause more harm than good, you can instruct your change control tool to put things back to the way they were.
Conclusion
Databases that showcase high performance are always riveted to an excellent physical design. Although the mentality of many corporations these days is to discount the value of planning and correctly creating a good physical database design, the fact is that you will be hard pressed to make a better contribution to a fast-moving system than when you lay the right foundation.
From discipline comes freedom. Does it take time and skill? Sure, but most good things do.
Share
Editorial contacts