An Introduction to Database Design

  • Comments posted to this topic are about the item An Introduction to Database Design

  • Excellent article paul.Couldn't ask much better than this.

    Great work done.

    Satnam

  • Very nice Paul. A good primer for the millions of simple database conversions out there.


    - Craig Farrell

    Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

    For better assistance in answering your questions[/url] | Forum Netiquette
    For index/tuning help, follow these directions.[/url] |Tally Tables[/url]

    Twitter: @AnyWayDBA

  • Hats off to you, Paul! Excellent article. Very beautifully explained via the use of a nice, gripping story that evolves itself into shape.

    Thank-you!

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com
    Be courteous. Drive responsibly.

    Follow me on
    Twitter: @sqltwins

  • Brilliant article!

    Well explained - I think even a DB novice would be able to understand this.

    I wish I could have given more stars 🙂

    Kelsey Thornton
    MBCS CITP

  • Excellent article!

    It really explains the basics of database design in a fun, not-too-technical manner.

    Great job!

    And it's been a long time since I've seen Alice and Bob 🙂

    (I guess the last time was when Trudy tried to hack into Bobs email account while impersonating Alice)

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • Hey Paul,

    I couldn't stop myself to say that your article was great and nicely present even a layman can understand what you trying to describe through your post.

    It just like reading some story about the SQL man.

    Good work keep it up..!!!

    Thanks,

    Anil Maharjan

  • Paul, thanks for this article and very needed for me at this time as I have an intern who is learning about SQL Server database design. I quickly printed your article out for him to read today and we can discuss later.

    Brad

  • Great article. I plan on sharing this with a few of my co-workers who are being pushed to learn SQL, yet don't understand DBs.

  • This is quite possibly one of the best technical articles for a wide audience that I have read in a long time, Paul. To anyone who is already well acquainted with database design, there won't be much new here but that isn't the target audience, is it? I really like how the story was used and how concepts were built upon each other in manageable chunks to get to the final point.

    I haven't rated an article in long while but had to stop to log in and rate this one. Anytime I need to explain any of the concepts of normalization or explain database design to a business person, I'll be including this article as a reference.

    While the database design aspect of this article may have been a review, I did learn something here - a great method for teaching and writing.

    __________________________________________________

    Mike Walsh
    SQL Server DBA
    Blog - www.straightpathsql.com/blog |Twitter

  • Its an awesome article I came across in recent past for freshers. I have suggested many freshers to see this article for understanding the table design.

    Nice example to demonstrate the complete idea of designing table.

    Great Work!!!

  • Good Work Paul!

    I haven't seen any article that explains the database designing concepts like a story,easy to understand format. 🙂

  • Nice work!! It's often said that to truly understand a concept you should be able to explain it to others in simple terms and you've definitely done that with this article. Simplicity to the point of brilliance. I shall refer to this when explaining database design concepts to customers.

  • I believe there are some serious flaws in this article. For example, recepts represent a historical record of a transaction occuring in a moment in time.

    If one normalizes the customer as is done in this example, and simply uses a foreign key in each receipt, what happens if a customer changes their address at some later time? or name? (people do get married).

    Now, ALL of the historical receipts return the NEW address or customer name, not the address or name of record at the time of the sale.

    This can't be correct, and would get most businesses in serious legal trouble. And I personally have seen this type of nonsense in many amateurish attempts at normalization.

    This presentation is oversimplified to the point of providing poor instruction I am afraid...

  • I should dd that bob's original paper receipts were MORE accurate than the DB design offered. At least the paper receipts would always return accurate info for the customer for the moment in time the sale was completed....

Viewing 15 posts - 1 through 15 (of 126 total)

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