Database Reference
In-Depth Information
Note
Designingananalyticaldatabaserequiresaradicallydifferentdesignmethodology
than the one you learned in this topic. If you determine that your organization re-
quires an analytical database, I strongly recommend that you acquire a good book
on the subject and learn how to design such a database properly.
Improving Processing Performance
This is still the most common reason that people feel compelled to bend or break the rules.
WheneveranRDBMStakeswhatseemstobeaninordinateamountoftimetoprocessmul-
titable queries or complex reports, many people believe that the solution to the problem is
to alter the underlying table structures. For example, they would have you modify a table
insuchawaythatitincludes
every
fieldnecessaryforthequeryorreport.Whilethismodi-
fication does indeed increase the speed at which the RDBMS processes the query or report
(particularly in older systems), it also introduces a number of new problems, such as unne-
cessaryduplicatefieldsandredundantdata.Thisisclearlynotadesirablesolution,because
it violates proper database design.
Unfortunately, real life is not as ideal as we would like it to be, so you will sometimes find
that you must decide between improving processing performance and holding to proper
design principles.
Is It Worth It?
When you take a moment to really think about this dilemma, you'll soon realize that the
question really isn't about performance; it's about
data integrity.
Anytime you break the
rules for the sake of performance (or any other reason, for that matter), you are surely
going to introduce data-integrity problems. The question you must ask yourself, then, is
this: Is the perceived increase in processing performance worth the price of reduced (and,
therefore, weakened) data integrity? As you well know, the consequences of making im-
prudent modifications to your data structures will eventually spread, like ripples in a pond,
throughout your database. Here are just a few of the problems you'll encounter.
•
Inconsistent data:
This is a result of introducing unnecessary duplicate fields into a
table. It will be your responsibility (or that of your application program) to ensure
that the data in these fields is synchronized; if you modify the value in a particular
duplicate field, you'll have to make certain that the same modification is made to
the remaining duplicate fields.
•
Redundant data:
Redundant data is also a result of introducing unnecessary duplic-
ate fields into a table. When you edit a particular value in a field that contains re-
