Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Bad Microsoft DB Schema Example Expand / Collapse
Author
Message
Posted Thursday, June 12, 2008 8:15 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Saturday, August 28, 2010 1:06 AM
Points: 19, Visits: 82
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?
Post #515955
Posted Thursday, June 12, 2008 8:18 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Wednesday, February 24, 2010 4:10 AM
Points: 1,553, Visits: 2,232
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


Posting Best Practices
Numbers / Tally Tables

SQL-4-Life
Post #515959
Posted Thursday, June 12, 2008 8:31 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 12:49 PM
Points: 22,529, Visits: 30,299
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

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #515968
Posted Thursday, June 12, 2008 8:45 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Saturday, August 28, 2010 1:06 AM
Points: 19, Visits: 82
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?
Post #515985
Posted Thursday, June 12, 2008 8:48 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Wednesday, February 24, 2010 4:10 AM
Points: 1,553, Visits: 2,232
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


Posting Best Practices
Numbers / Tally Tables

SQL-4-Life
Post #515989
Posted Thursday, June 12, 2008 8:53 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Saturday, August 28, 2010 1:06 AM
Points: 19, Visits: 82
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 query


Hehe, yes of course. :D 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?
Post #515997
Posted Thursday, June 12, 2008 10:01 AM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 12:49 PM
Points: 22,529, Visits: 30,299
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.




Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #516066
Posted Thursday, June 12, 2008 11:18 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 1:48 PM
Points: 14,836, Visits: 27,313
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 Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #516113
Posted Thursday, June 12, 2008 11:31 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 9:41 PM
Points: 7,090, Visits: 14,715
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?
Post #516123
Posted Thursday, June 12, 2008 11:38 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Saturday, August 28, 2010 1:06 AM
Points: 19, Visits: 82
It seems that some of you have missed my link:
source page
Post #516135
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse