Book Review: Professional SQL Server 2000 Database Design

Thursday Jan 17th 2002 by Danny Lesandrini

Danny Lesandrini explores a database design resource 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.

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.

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.

Buy Professional SQL Server Database Design

See All Articles by Columnist Danny Lesandrini