One problem that must be confronted by modern DBAs is coping with the mad rush to “get it done NOW!” Although such a mindset is common throughout business these days, it is particularly common when moving from traditional development to web-based application development. Indeed, the phrase “Internet time” is sometimes used to describe this phenomenon. Basically, when a business starts operating on “Internet time” things move faster. One “web month” is said to be equivalent to about three standard months. The nugget of truth in this load of malarkey is that web projects move very fast for a number of reasons:
- Because business executives want to conduct more and more business over the web to save costs and to connect better with their clients.
- Because someone read an article in an airline magazine (or talked to a consultant or analyst) where it was mentioned that web projects should move fast.
- Because everyone else is moving fast so you better move fast too or risk losing business.
Well, two of these three reasons are quite valid. I’m sure you may have heard other reasons for rapid application development (RAD). And sometimes RAD is required for certain projects. But RAD is bad for database design. Why? Applications are temporary but the data is permanent. Organizations are forever coding and re-coding their applications – sometimes the next incarnation of an application is being developed before the last one even has been moved to production.
But when did you ever throw away data? Oh, sure, you may redesign a database or move from one DBMS to another. But what did you do? Chances are you saved the data and migrated it from the old database to the new one. Some changes had to be made, maybe some external data was purchased to combine with the existing data, and most likely some parts of the database were not completely populated. But data lives forever.
To better enable you to glean value from your data it is wise to take care when designing the database. A well-designed database is easy to navigate and therefore, it is easier to retrieve meaningful data from the database.
When rushed for time some DBAs resort to designing the database with output in mind. This can lead to flaws such as storing numbers in character columns because leading zeroes need to be displayed on reports. This is usually a bad idea with a relational database. It is better to let the database system perform the edit-checking to ensure that only numbers are stored in the column. If the column is created as a character column then the developer will need to program edit-checks to validate that only numeric data is stored in the column. It is better in terms of integrity and efficiency to store the data based on its domain. Users and programmers can format the data for display instead of forcing the data into display mode for storage in the database.
Another database design problem that speed may induce is assigning inappropriate table and column names. Database names that are used to store data should be as descriptive as possible to allow the tables and columns to self-document themselves, at least to some extent. Application programmers are notorious for creating database naming problems, such as using screen variable names for columns or coded jumbles of letters and numbers for table names.
A proper up-front analysis and design requires thought and consideration, and therefore time. Without the benefit of this process the database is unlikely to be flexible enough to easily support the changing requirements of the user. And a rushed database design will likely introduce anomalous data and integrity problems that will be passed down from system to system and database to database.
So DBAs, here is a call to action! Fight the rush-rush, do it now, attitude and take the time required to design your databases effectively, efficiently, and appropriately for the business. In the long run, your company will be glad that you did…