Bad Microsoft DB Schema Example
-
OK, generally I try to avoid or ignore bad things. But I think this is important. I'm relearning about DB design concepts and I stumbled upon this Microsoft examples page. I haven't looked closely to all of them but the one example that even has a video is 3rd example.
And here's the image:
What really bothers me is that they have a "real-world" examples and then they create a table Products that holds the data for both books and coffee!
So, even if there is a store that sells books and coffee (I guess it's possible), wouldn't it be better if there was a general "Products" table and then two separate tables for "Books" and "Coffee" with specific columns?
Somebody enlighten me please why they put such example on their official page and tell me if I'm right. What if the store sold just 10 different product and each product has only 10 specific columns - a table with 100+ columns! I am 98% sure this is really bad table design and should be avoided.
p.s.: A link with better real-world examples possible with tables?
-
Other thing is to maybe create a ProductsBook and ProductsFood table?
What do people think of this?
----------------------------------------------
Try to learn something about everything and everything about something. - Thomas Henry Huxley:w00t:
SQL-4-Life
Posting Best Practices[/url]
Numbers / Tally Tables[/url] -
Not knowing the full details of the example it is difficult to make a judgement. One thing to remember is that while designing a database for a production application (as opposed to one for database class) you will make decisions to denormalize a design for performance reasons. Although it may make sense to split off those aspects of the data that relate only to books or coffee into their own table, you may experience performance issues as you increase the number of tables you have to join in a query.
😎
-
Lynn Pettis (6/12/2008)
Not knowing the full details of the example it is difficult to make a judgement. One thing to remember is that while designing a database for a production application (as opposed to one for database class) you will make decisions to denormalize a design for performance reasons. Although it may make sense to split off those aspects of the data that relate only to books or coffee into their own table, you may experience performance issues as you increase the number of tables you have to join in a query.😎
As in? Like when you'd want to see all data of all products that were ordered on a certain date? If it's just one Products table this is fast as opposed to each product in a separate table? Wouldn't that query look a mess and all columns irrelevant to a product (book_author for coffee) would be null?
What if you have 50 products?
-
WEll you need to remember that you shouldn't use SELECT * so you should return the book columns in a food query
----------------------------------------------
Try to learn something about everything and everything about something. - Thomas Henry Huxley:w00t:
SQL-4-Life
Posting Best Practices[/url]
Numbers / Tally Tables[/url] -
Christopher Stobbs (6/12/2008)
WEll you need to remember that you shouldn't use SELECT * so you should return the book columns in a food queryHehe, yes of course. 😀 How would you return just the relevant product data for each product?
Anyway, so this example diagram is not so bad after all? And just because of the performance issues?
-
I'm not making any judgements on the design. I was trying to point out that somethings that don't seem right could be based on other factors.
You could desgin a database system that totally eliminates all null values in tables. It has a name, 6th normal form. Would I implement such a design for an OLTP system, no. Biggest reason, performance. The number of table joins required to pull data together would be costly.
Also, in this design, you are only looking at the database schema. I have no idea what the UI design is. It may take into account the different products and use different screens or web pages dependent on the product type. From what was posted, that is unknown.
Also, you should never use a SELECT * FROM ... in your production code.
😎
-
Unless there's a pretty major application or performance reason, I'd have to agree that this is a crappy "real world" example.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
Grant Fritchey (6/12/2008)
Unless there's a pretty major application or performance reason, I'd have to agree that this is a crappy "real world" example.Not fully understanding the background on how that was used - was it being portrayed as being a crappy model example or was this the final result? Because that's a fairly ugly example to be sure.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again? -
It seems that some of you have missed my link:
-
It doesn't give enough details on that page to determine if there's a funky business requirement or even if that initial model is updated in the demo. I'm still falling on the side of it being junk.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
Just to add a practical reason why the data model is poor, trying adding a uniqueness constraint on Product.book_isbn. Since the value will be null for all of the non-book products, the constraint cannot be created.
If you want to learn about data modeling from books, here are my recommendatations:
HANDBOOK OF RELATIONAL DATABASE DESIGN
by C. C. Fleming and Barbara von Halle
Addison-Wesley; ISBN 0-201-11434-8.
http://www.amazon.com/exec/obidos/search-handle-form/104-9318903-3039129
The Data Modeling Handbook : A Best-Practice Approach to Building Quality Data Models by Michael Reingruber, William W. Gregory (Contributor)
Publisher: John Wiley & Sons; ISBN: 0471052906; (December 1994)
SQL = Scarcely Qualifies as a Language
-
okkko (6/12/2008)
So, even if there is a store that sells books and coffee (I guess it's possible), wouldn't it be better if there was a general "Products" table and then two separate tables for "Books" and "Coffee" with specific columns?I'm not going to defend the data model... it is likely to violate normalization rules unless there are some extremely strange business requirements. But to the question of a store that sells both books and coffee, two common stores around where I live are Barnes and Noble and Books-A-Million. Both are primarily book sellers, but they also have a cafe area.
K. Brian Kelley
@kbriankelley -
One thing to think about ....
If you have separate tables for each product, what happens if they add a product? Someone needs to add at least one a new tables and whatever else goes with it.
By having one table with all products then there is no need to add new tables for new products.
Alvin Ramard
Memphis PASS Chapter[/url]All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
-
Alvin Ramard (8/1/2008)
One thing to think about ....If you have separate tables for each product, what happens if they add a product? Someone needs to add at least one a new tables and whatever else goes with it.
By having one table with all products then there is no need to add new tables for new products.
But if you follow the model given out logically, adding a 3rd product type would add a 3rd set of columns to the table. Let's say our bookstore now sells pets. That means you have columns for:
- Animals
- Books
- Coffee
in that one table. Since those should be mutually exclusive sets, that means 2 sets of columns will always be nulls, etc. You get the idea. It would probably be better to go to separate tables, if that's the case.
K. Brian Kelley
@kbriankelley
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply