29
Chapter 2: Data Architecture
2
Issues and Objections
There are some objections to the Smart Database Design framework addressed here. Some
say that buying more hardware is the best way to improve performance. Although this is a
viable and sometimes necessary solution, it can mask underlying data architecture issues
that will probably crop up later. Performance problems tend to grow exponentially as DB
size grows, whereas hardware performance grows more or less linearly over time. You can
almost predict when the “best” hardware available no longer suffi ces to get acceptable per-
formance. Sometimes companies spend incredible amounts to upgrade their hardware and
see little or no improvement because the bottleneck is the transaction locking and blocking
and poor code. Sometimes, a faster CPU only waits faster. Strategically, reducing the work-
load is cheaper than increasing the capacity of the hardware.Some argue that they would like to apply Smart Database Design but can’t because the
database is a third-party database, and they can’t modify the schema or the code. True, for
most third-party products, the database schema and queries are not open for optimization,
and this can be frustrating if the database needs optimization. However, most vendors are
interested in improving their product and keeping their clients happy. (Both clients and
vendors have contracted with the author to help identify areas of opportunity and suggest
solutions for the next revision.)Some say they’d like to apply Smart Database Design, but they can’t because any change to
the schema would break hundreds of other objects. It’s true — databases without abstrac-
tion layers are expensive to alter. An abstraction layer decouples the database from the
client applications, making it possible to change the database component without affecting
the client applications. In the absence of a well-designed abstraction layer, the fi rst step
toward gaining system performance is to create one. As expensive as it may seem to refac-
tor the database and every application so that all communications go through an abstrac-
tion layer, the cost of not doing so could be that IT can’t respond to the organization’s
needs, forcing the company to outsource or develop wasteful extra databases. At the worst,
the failure of the database to be extensible could force the end of the organization.In both the case of the third-party database and the lack of abstraction, it’s still a good
idea to optimize at the lowest level possible and then move up the layers. However, the
best performance gains are made when you can start optimizing at the lowest level of the
database component, the physical schema.Summary
This chapter presented the concept of the Information Architecture Principle, unpacked the
six database objectives, and then discussed the Smart Database Design, showing the depen-
dencies between the layers and how each layer enables the next layer.c02.indd 29c02.indd 29 7/30/2012 4:07:54 PM7/30/2012 4:07:54 PM
http://www.it-ebooks.info