Results 1 to 12 of 12
  1. #1
    Join Date
    Nov 2004
    Posts
    7

    Unanswered: Best Design Practice?

    I'm building a database that has maybe four unique tables Student,
    Advertiser, Employee, maybe Account. Three of the four table (Student,
    Advertiser, Employee) have something in common in which they all contain
    fields such as emailAddress, password, role, isAccountActive, etc. which
    allow them to access their respected data. However, is it best practice to
    build a fourth table which contain Account information or should I just
    include that information in their respected tables?

    My thinking is that if you have a fourth table such as Account then you can
    manage all accounts (Student, Advertiser, Employee) from one table, but as
    the database gets more in-depth you have to build more and more complex
    stored procedure to do simply task such as update, delete, select, etc.

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    i would probably combine all 4 tables into one because of the columns the first three have in common

    it really depends on how many columns they don't have in common
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  3. #3
    Join Date
    Feb 2004
    Location
    San Antonio, TX
    Posts
    565

  4. #4
    Join Date
    Feb 2004
    Location
    San Antonio, TX
    Posts
    565
    in addition, i truly beleive that the data model is entirely indicative of the business model or in other words, the data model already exists it's your job to discover it.

    the rules are defined as a dictum for all to follow. some follow them more strictly than others and some bend the rules to accomodate performance and simplicity requirements.

    as a designer, you should know the rules before you can intelligently break them.
    Last edited by Ruprect; 12-11-04 at 14:54.

  5. #5
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Ruprect
    the rules are defined as a dictum for all to follow. some follow them more strictly than others and some bend the rules to accomodate performance and simplicity requirements.
    you'll love this discussion, then --

    http://www.kottke.org/04/10/normalized-data

    by the way, i trust that remark about making an attempt to read a web page on amazon was not directed at me
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  6. #6
    Join Date
    Feb 2004
    Location
    San Antonio, TX
    Posts
    565
    Quote Originally Posted by r937
    you'll love this discussion, then --

    http://www.kottke.org/04/10/normalized-data

    by the way, i trust that remark about making an attempt to read a web page on amazon was not directed at me

    what the hell are you talking about?

    by the way i read your link and that is just another example of a application developer assuming that he has the chops for db work. just because you can type create table create view and creat proc , in no way makes you a dba it just makes us all look bad when the shiat hits the fan and said app developer cant fix it.
    I hate this subject so much that just a 5 minute exposure to this article has totaly pissed me off.

    "ooooooohhh i hate that rabbit"
    Last edited by Ruprect; 12-12-04 at 04:37.

  7. #7
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Ruprect
    what the hell are you talking about?
    i was talking about your comment in post #3 which immediately followed my post #2 -- i assume your rather arrogant comment "try reading this" wasn't directed at me

    you should read that kottke article a little more closely, it is the comments to the article that are all the fun, kottke himself is not a dba, he was just raising the issue

    if the name kottke means nothing to you, that's fine, i guess you haven't been around the web much

    the name cal henderson may not mean anything either, but he is the one who developed the back end for flickr, and you really should read his powerpoint presentation, flickr is an amazing project and i personally don't have th chops to do anything remotely like that

    maybe you do, though

    Last edited by r937; 12-12-04 at 07:48.
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  8. #8
    Join Date
    Feb 2004
    Location
    San Antonio, TX
    Posts
    565
    R2D2.

    against my better judgement, I will issue the following statement.

    my initial post was directed to the guy who started this thread.
    my follow up post was a kind of postscript to the previous post and once again was directed to the guy who started this thread

    at no point were you even on my radar.
    Last edited by Ruprect; 12-12-04 at 11:05.

  9. #9
    Join Date
    Nov 2004
    Posts
    7
    I just want to thank you guys for the help. I have now made a sound decision on my database design.

  10. #10
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    ...and off to the holy quest, to seek the holy model...

    ...and sometimes our heated discussions remind me of this opening scene...
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  11. #11
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by Ruprect
    at no point were you even on my radar.
    oh, that's so adult of you, rupert
    rudy.ca | @rudydotca
    Buy my SitePoint book: Simply SQL

  12. #12
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Neutral corners, please!
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •