Professional SQL Server 2000 Database Design

by Louis Davidson

SQL Server 2000 is the latest and most powerful version of Microsoft's data warehousing and relational database management system. However, unless a database is designed correctly the powerful... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 1861004761
• ISBN13: 9781861004765
• Release Date: January 2001
• Publisher: Wrox Press
• Length: 607 Pages
• Weight: 2.35 lbs.
• Dimensions: 1.3" x 7.3" x 9.2"

Customer Reviews

Not the be all end all, but a good place to start

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.

Soup To Nuts Engineering For Database Design, A Keeper

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.

Mostly OK - but be skeptical of some suggestions!

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.

Pleasant balance between theory and practice

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!

This is an exceptionaly well done book

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.