Database Reference
In-Depth Information
decisions are about trade-offs: do you really want to spend hundreds or
thousands of dollars for a 10 percent performance boost?
In the long run, a better solution can be to redesign a poorly designed
database. The horrible testing database we discussed probably wouldn't
have scaled very well. The application had to do many tricks in order to
save and retrieve the data. This created far more work than would have
been required in a well-designed system. Don't get me wrong—I am not
saying that all performance problems stem from bad design, but often bad
design causes problems that can't be corrected without a redesign. If the
data model is sound from the get-go, you can focus your energy on actu-
ally tuning the database using indexes, statistics, or even access methods.
Again, just like a house, a database that has a solid foundation lets you re-
pair the problems that occur.
This topic is written as a step-by-step, process-oriented look at data mod-
eling. You will walk through a real-world project from start to finish. Your
journey will follow Mountain View Music, a fictitious small online music
retailer that is in the process of redesigning its current system. You will
start with a little theory and work toward the final implementation of the
new database on Microsoft SQL Server 2008.
The main topic of this topic is not data modeling theory, but we give
you enough information on theory to start constructing a sound model. We
focus on the things you need to be aware of when designing a model for
SQL Server.
This topic is divided into four parts; each one builds on the preceding
one as we walk you through our retailer scenario. In the first four chapters
we look at theory, such as logical and physical elements and normalization.
In Part II, we explain how to gather and interpret the requirements of the
company. Part III finds us actually building the logical model. Finally, in
Part IV, we build the physical model and implement it on SQL Server.
Throughout this topic we focus on the fact that we are designing this
data model to ultimately be implemented on SQL Server. For that reason,
we point out the correct decisions to make based on the capabilities of
SQL Server that will help to produce an efficient model for that platform.
We go through all this in detail throughout the topic, but let's take a brief
look at each area and see what lies ahead.
Search WWH ::
Custom Search