54 of 57 people found the following review helpful:
3.0 out of 5 stars
disappointing, August 9, 2002
This review is from: Professional SQL Server 2000 Database Design (Paperback)
My background is as an ASP developer and new dedicated DBA / Data Architect. I've done pretty extensive data modeling and implementation for several small to medium sized ASP applications. I am a big fan of the Wrox P2P series. This is my 8th Wrox purchase.
I was disappointed in this book, but I'm having trouble putting my finger on exactly why I was disappointed. I read every word, which is rare for a technical book, but I just don't feel like I learned in the areas that I really wanted to learn. My two main goals for this read were to learn how to better build business rules into my databases and to reinforce and validate data modeling techniques I have been taught from mentors.
Extensive coverage is given in the first half of the book to the logical design (extensive to the point of obnoxious). Tips on how to break down your notes for entities and relationships and the like are abundant. A theme I kept repeating to myself over and over as I read was that this is big-time overkill for anything other than an enterprise-scale application. I'm as big an advocate of documenting client interviews as the next guy, but come on - breaking down every paragraph looking for verbs is just overkill. There was no advice given on how to solicit valuable information. Reports are discussed, but I'm a firm believer that reports can tell you much more about an application's true value than anything else. I very much prefer to start by asking the question "What information do you need from the system to do your job better than you do today?" than to start out by asking, "What do you do all day?" I find it the only way to break users out of the paradigm that they have worked in for so long and it leads to much more innovative useful applications. Nothing like this was in the book. I learned how to go through notes that magically appear, and that reports will shed light on missed pieces of information and new pieces of functionality, but who doesn't know that that has designed a database?
Davidson is a BIG advocate of normalization. And while there is no substitute for a well-normalized database for application stability and data integrity, Davidson advocates the breaking out of tables for the most meaningless of reasons. Those that develop applications on top of his databases much hate all the extra work he builds in. I disagree with his assertion that the database should be built to anticipate any possible changes to the user-expected data. You will spend forever trying to anticipate changes, and even longer coding over the massive database you have built. For example, in order to store a user's address, Davidson advocates a six-table structure with five joins. Are you kidding me? What coder wants to deal with all that just for the possibility that some time down the road the users may want to add Address Line 10 to the application.
Davidson also follows an annoying pattern for demonstrating his normalization techniques. He presents a data model with problems, introduces a concept, applies the concept to the tables and comes up with a better model. This is great, except that he continues to build on the same example throughout the book. So, other than the very last model, all the ones before it are incorrect. You have to read every word in order to get to the correct answer. It makes it impossible to pick up a chapter to use as a reference, because if you create a solution similar to the one demonstrated, you will have an improperly normalized database. Fine for a book you read front to back, but not so good for a reference manual.
The implementation details of the book were even more disappointing. Davidson is not an advocate of an N-Tier approach to coding. He believes that as many of the business rules that can be incorporated into the database should be built there. He openly says that he butts heads with his developers and system architects over this issue. I'm not surprised. While I suppose that building the business rules into the database is good for data integrity, I think the biggest advantage for the DBA is job security. I believe that a well-built database should be flexible to changes in business rules and that the data should be stored independent of those rules whenever possible. We all know rules change, and I don't like messing with a production database if I can help it. I would rather have flexibility in the model and trust my business tier coders to do their job.
The chapters on Stored Procedures, UDFs, Triggers, and the like are too complicated for a newbie and too un-detailed for an experienced developer. I found Professional SQL Server 2000 Programming by Robert Vieira a much better reference for both the basics and best practices.
I guess I've written enough. I still feel there is value in this book. For someone that has never designed a database before or has no formal training, it may be a good reference, but I fear it will be too complicated for a true newbie. There are valuable bits of advice and I broke out my highlighter more than once. In particular, Davidson offers some simple modes for overcoming common problems such as attribute change history.
Three stars - I just had too many disagreements with the author to go any higher.
-HawkeyeGK
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
25 of 25 people found the following review helpful:
4.0 out of 5 stars
Mostly OK - but be skeptical of some suggestions!, September 3, 2001
This review is from: Professional SQL Server 2000 Database Design (Paperback)
After some background on databases, we get started on requirements gathering - talk to customers and gather as much information as possible. Analyse this to identify entities/attributes/domains/relationships. Sub-types receive good discussion. A brief overview of relational concepts is given (enough to whet your appetite - but no more). The IDEF1X notation is used throughout - personally I prefer the "crow's foot" notation. Normal forms get reasonable coverage up to 4NF. 5NF and DKNF are mentioned only briefly. The second half of the book considers implementation of a data model in SQLServer. In addition to creating tables and relationships, also discussed are UDFs, constraints, triggers, stored-procs, views, and transactions. Various other topics such as reporting, archiving, project planning, hardware, and physical architectures also get an overview.
There are certain things in the book I don't like. Davidson insists on calling primary keys "pointers". No - they are most certainly not! He also recommends every table in a database has an identity column as it's primary key - even when a suitable primary key does exist. The "real" primary key is then implemented as an alternate key. To quote the book - "In logical modeling, we chose to use a 4 byte integer pointer for entity primary keys", "Every table will have a single meaningless primary key". Controversial to say the least! A rather wacky naming convention is also proposed, leading to such wonderful constraint names as chkAlbum$catalogNumber$function$artist$catalogNumberValidate. Each to his own, I guess. Oh yes, and let's not to forget the obligatory mistake of talking about "null values" - AAGGHH!
If you are after a book purely about data modelling then you may want to consider a different book, such as "Data Modeling Essentials" by Simsion. However if you want a book that considers data modelling in the context of SQLServer, then this may be the book for you - just take some suggestions with a large pinch of salt.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
18 of 19 people found the following review helpful:
5.0 out of 5 stars
Soup To Nuts Engineering For Database Design, A Keeper, November 25, 2001
This review is from: Professional SQL Server 2000 Database Design (Paperback)
I am old veteran engineer (hardware and software) working mostly alone on a new project for the .NET platform with SQL Server underneath for data. I am using Embarcadero ERStudio for database modeling. I have a great library (more than 20 titles) on relational database modeling and design; but this is the one that I keep on my desk. I am pretty much following this book step by step on my current project. The author uses the IDEF1X diagramming notation for logical design, which, quite conveniently, is what I use in ERStudio.
This is a great guide for the experienced professional developer who may do database design only occasionally. Examples are all from the business world. The book is filled with code, which can be downloaded.
The 606-page book has two sections: (1) logical design and (2) physical design and implementation. So far I have only completed the first section, but looking ahead it seems that this book will carry me all the way through actual testing of my finished application.
The name suggests, perhaps improperly, a particular connection to Microsoft's SQL Server. The book addresses design and implementation issues on a general relational/SQL level; and the specific setups and interfaces (the MMC for example) of Microsoft's latest relational database, SQL Server 2000, are absent. I do not see a single SQL Server screen shot among the hundreds of illustrations. Specifics of setting up SQL Server are available in dozens of other books. This is a software engineering book, not a system administration book. Those making their first attempt at relational design will find the book a bit too challenging unless they are serious professionals.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
