Level 3: Relational Database Design

  • Greg Larsen


    Points: 20716

    Comments posted to this topic are about the item Level 3: Relational Database Design

    Gregory A. Larsen, MVP

  • dooh.register

    SSC Enthusiast

    Points: 114

    Why the article is titled "Relational Database Design" while it presents bunch of DDL&DML statements and shows implementation rather than design?

  • Greg Larsen


    Points: 20716

    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.


    Gregory A. Larsen, MVP

  • Charlene.Wright

    SSC Enthusiast

    Points: 188

    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"?


  • zorglub2015

    SSC Enthusiast

    Points: 151

    I was going to ask the same question!

  • TomThomson

    SSC Guru

    Points: 104773

    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.


  • Bill Talada


    Points: 11956

    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.

  • Eric M Russell

    SSC Guru

    Points: 125100

    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 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply