Rating: 
Summary: disappointing
Review: 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
Rating: 
Summary: Not the be all end all, but a good place to start
Review: This is the kind of book that will help the developer who has been working in Access and now finds the company has up sized to SQL Server. It's one of those books you add to your library that you read to make sure you have all the basics covered. I also like the fact that it gave the developer a look at the DBA side of the coin, which I'm sure will help the guy or gal who finds their the whole ball of SQL Server wax and has to do it all from developer to DBA.
Well Worth the investment in time and money.
| 
