September 5, 2011 at 9:07 am
Comments posted to this topic are about the item Level 3: Relational Database Design
Gregory A. Larsen, MVP
November 9, 2011 at 12:04 pm
Why the article is titled "Relational Database Design" while it presents bunch of DDL&DML statements and shows implementation rather than design?
November 16, 2011 at 6:04 am
Thank you for pointing out the title problem. For some reason when this article got posted it was posted with a different title then was original contained in my article. The site owner has now corrected the title.
Greg
Gregory A. Larsen, MVP
December 18, 2014 at 3:20 pm
Hi Mr. Larsen,
Thank you for the stairway!
It works as is; however, in Listing 5, for naming consistency, shouldn't "FK_Reservation_CustomerPaymentType" be "FK_Reservation_CustomerId"?
Charlene
May 13, 2015 at 1:18 am
I was going to ask the same question!
May 13, 2015 at 2:35 pm
The title change certainly reduced the awfulness, but what I see is a rather sloppy diagram and some code that maiht represent one possinle interpretation of it. What fields are the sources of which pointers? What fields are the destinations? Neither is at all clear.
In what sense can the diagram be interpreted as a relational model? A relational model of some thing has to conform to relational principles, and the only way one can discover that this diagram does is to look at the SQL code provided and assume that the code determines what the diagram means. So the way to implement a relational model in SQL is to have a relational model in SQL and then draw a diagram representing (albeit rather sloppily) the table and constraints structure that that model represents and say that's the model the code was supposed to implement? Which is the cart and which is the horse here?
I realised this is an ancient article, and I should have commented years ago. But someone else commented ealier today, and that drew my attention to it, so I commented now.
Tom
August 2, 2017 at 1:56 pm
There are so many flaws in the design and implementation that this should earn a failing grade.
Why use unicode sometimes?
Many of the data types are deprecated.
Never use smallmoney or money since those weird data types will store fractions of pennies.
The formatting is unhelpful.
The design doesn't seem to have any real intelligence to it.
Misspellings and abbreviations abound.
I don't see any alternate keys, which can happen but is extremely rare in most designs.
There are no specs against which a design is validated.
The tibbling naming standards used are pathetic.
Basic columns such as amounts are missing.
Beginners will start off on the wrong foot if they read this article.
I suggest buying "The Data Model Scorecard" for learning correct principles of design.
August 2, 2017 at 2:27 pm
The Data Modeling Scorecard website looks interesting. I don't know how I missed hearing about this guy Steve Hoberman.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply