Rating: 
Summary: Mostly OK - but be skeptical of some suggestions!
Review: 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.
Rating:
Summary: Buenisimo para todo nivel!
Review: Este libro no es solo para profesionales, tambi?n sirve para aquellas personas que poseen conocimientos b?sicos de SQL Server 2000 y de Dise?o de Base de Datos y desean ampliar sus conocimientos. Te lleva de la mano en todo momento, desde el momento de la toma de informaci?n y las entrevistas con el cliente hasta el proceso de Dise?o de la Base de Datos como tal en SQL Server 2000. Adem?s utiliza un lenguaje muy cotidiano, lo cual hace el libro un poco particular.
Rating:
Summary: Buenisimo para todo nivel!
Review: Este libro no es solo para profesionales, también sirve para aquellas personas que poseen conocimientos básicos de SQL Server 2000 y de Diseño de Base de Datos y desean ampliar sus conocimientos. Te lleva de la mano en todo momento, desde el momento de la toma de información y las entrevistas con el cliente hasta el proceso de Diseño de la Base de Datos como tal en SQL Server 2000. Además utiliza un lenguaje muy cotidiano, lo cual hace el libro un poco particular.
Rating: 
Summary: Soup To Nuts Engineering For Database Design, A Keeper
Review: 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.
Rating:
Summary: This is an exceptionaly well done book
Review: I find this book much better than most other wrox books. Most DB design books were either unweildy college textbooks, or don't go in much detail. This book takes all the details of college textbooks and makes it all easy to learn. He even deals with 4th, 5th, and domain key normal form and gets into guidelines with complex (beyond the ability of simple constraints) integry enforcement and ideas on how to implement business rule enforcement for those certain companies that like to put their business logic in the back-end. He also goes through in detail of the transition from the logical model to the physical model. I also learned that columns like category1, category2, category3... violate the lowest of normal forms - first normal form . I still think I would rather deal with legacy schema with this problem than designs that duplicate the rows and double up the PK with an index number (JobID, CategoryNumber). But anyway, this is a great DB design book and I suggest you get it. I will be hunting down more books from this author.
Rating:
Summary: This is an exceptionaly well done book
Review: I find this book much better than most other wrox books. Most DB design books were either unweildy college textbooks, or don't go in much detail. This book takes all the details of college textbooks and makes it all easy to learn. He even deals with 4th, 5th, and domain key normal form and gets into guidelines with complex (beyond the ability of simple constraints) integry enforcement and ideas on how to implement business rule enforcement for those certain companies that like to put their business logic in the back-end. He also goes through in detail of the transition from the logical model to the physical model. I also learned that columns like category1, category2, category3... violate the lowest of normal forms - first normal form . I still think I would rather deal with legacy schema with this problem than designs that duplicate the rows and double up the PK with an index number (JobID, CategoryNumber). But anyway, this is a great DB design book and I suggest you get it. I will be hunting down more books from this author.
Rating:
Summary: Pleasant balance between theory and practice
Review: I have been searching for a book that covers both database design theory and outlines theory by practicle examples. This is a book where you will get this! Even better, throughout the book a banking-checkingaccount database CASE is presented, which raises the level of the book (in my opinion) even further. Instead of the always present customer/order or name/address examples you get 'the real thing' here. If you are looking for a theoretical foundation which is not dry at all this is the book to buy!
Rating: 
Summary: Why WROX is overrated
Review: I've been reading many reviews about WROX books and people make it sound like WROX is the next O'Reilly of tech books. So when I needed a MSS-QL design book I figured I'd give them a try, especially after their good reviews on this book. Leave it to say I'm very dissapointed. I own well over 100 tech books and this is by far the most wordy book I've read. This extra detail of wordiness does not offer some great insight into the subject but seems to serve as a way for the author(s) to turn what should be a 250 page book into a long and boring 600 page read. I prefer books that get "right to the point". Theory is good and all but not in excessiveness. What it really boils down to is time, this book doubles my pacing and doesn't offer more in the line of education. If I wanted to read something big, I'll buy 'War & Peace'. Bigger is NOT always better.
Rating:
Summary: Why WROX is overrated
Review: I've been reading many reviews about WROX books and people make it sound like WROX is the next O'Reilly of tech books. So when I needed a MSS-QL design book I figured I'd give them a try, especially after their good reviews on this book. Leave it to say I'm very dissapointed. I own well over 100 tech books and this is by far the most wordy book I've read. This extra detail of wordiness does not offer some great insight into the subject but seems to serve as a way for the author(s) to turn what should be a 250 page book into a long and boring 600 page read. I prefer books that get "right to the point". Theory is good and all but not in excessiveness. What it really boils down to is time, this book doubles my pacing and doesn't offer more in the line of education. If I wanted to read something big, I'll buy 'War & Peace'. Bigger is NOT always better.
Rating:
Summary: Not the be all end all, but a good place to start
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
| 
