Having read a lot of SQL Server books written for DBAs, I
was anxious to see what Louis Davidson had to say about SQL Server 2000 from the
developer’s point of view in
Professional SQL Server 2000 Database Design, published by
Wrox Press. In his “Who is this book for?”
paragraph, he indicates that this book is aimed at developers who have an
interest in learning more about general relational database design issues. The
author sticks to that goal, providing sample code, case studies and a refreshing
first-person approach that makes for an easy read from what could be considered a very
dry subject.
The book is divided into 2 basic parts: Logical Design and
Physical Design.
Logical Design Section
In addition to what you would expect, such as discussions about database methodologies
and normalization techniques, this section spends a good deal of time on the process
of gathering requirements and working with clients to create the right data
model.
The author provides good advice about how to conduct client
interviews, what you need to know about database prototypes and why it’s
critical to document customer sign off at various points during the discovery
process. Oddly enough, I found this part of the book to be the most valuable. We
all know that to make a project successful, we need good communication with the
client, but I hazard to guess that we have all made mistakes in this regard.
Davidson does a great job of outlining the important questions that need asking
and emphasizing the importance of documentation. This section of the book alone
could be worth the price of admission!
The remainder of the Logical
Design section is devoted to fundamental database concepts, including entities,
attributes, relationships and the rules for normalization. I’ve always found
this topic to be tedious, but necessary. Although being familiar with these
principals and having developed databases for some years, I bit the bullet and
read every word, every page of this section. Advice such as “divorce yourself
from the final structure” serves as a good reminder not to rush headlong into
designing the physical structure before you’ve carefully created a logical model
tailored for this particular client and project. Good reminders, good chapters,
but still tedious to me.
Physical Design Section
This is where the
book explains how to create the actual database objects, such as tables,
triggers, views and stored procs. At times, the discussion became vague and the
author simply stated possible options. For example, should you use a thin client
or thick? Classic client server or n-tiered configuration? Is a million rows a
lot of data or not? Should you worry about 100 concurrent users or wait till
that number grows to a thousand? Though it’s appropriate not to try to
definitively answer these questions (no single answer will fit all projects), I
would have none the less liked to hear more of the author’s opinion in what I
call “what if” scenarios. “What if I’m creating an office productivity
application for use within our LAN?” “What if my database will serve data to
users through our company Intranet?” Questions of this nature help me identify
issues that relate to my current project requests.
The next few chapters
discuss SQL Server 2000 specific issues such as selecting the appropriate data
types, creating tables, triggers, etc. The discussion of User Defined Functions
was very good and the sample code was practical and extendable to real life
issues. I also enjoyed reading his opinions on the implementation of triggers,
both the AFTER and INSTEAD OF variety. Davidson also shares his own ideas about
object naming, which is an important aspect to design.
The final chapters of the book, Determining Hardware Requirements and Completing The
Project, were quite useful. The code for the book, including a rather nice
stored proc for calculating index space is available at the
Wrox Web site for this book. While the information about tuning server properties
such as memory and CPU settings was useful, I found the database performance
tuning suggestions to be more interesting and applicable to me as a developer.
Conclusion
To whom would I recommend this book? That’s a
really hard question. If you are an experienced SQL Server 2000 DBA, then you
probably won’t extract a lot of new information from this book. If you’re only
familiar with SQL Server 7, then you’ll probably get your money’s worth from the
discussion of SQL Server 2000 specific features such as User Defined Functions,
instead of triggers and Partitioned Views, though there are other good
sources for that information.
If you are a Microsoft Access developer
who wishes to upgrade your skills, then this is an excellent book for you, even
if you already understand design issues such as normalization, transactions and
the relational design model.
If you know nothing about databases but
would like to, then this book is a must-have. It covers every aspect of database
design and does so in as appealing manner as is possible. Of course, if you fall
into this category, be warned: database design is not for the faint of heart.
Teaching yourself relational design through self-study takes discipline, even
with a resource as complete as Professional SQL Server Database Design.
On a final note, Davidson’s discussion of how each design step relates
to the overall project is very useful to those who are starting a new project.
Independent consultants who regularly work with clients to determine project
requirements will find this book invaluable. It’s a book I’ll keep on my shelf
and review each time I’m asked to create a new database.
