SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Guru toasti's Avatar
    Join Date
    Feb 2004
    Location
    Grahamstown
    Posts
    634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    To relate or not to relate, that is the question

    I have always believed that normalized databases are the way to go..but i never really thought about it.

    The other day i was working on a project, and the project leader looked at my nice normalized data structure and said: "what is this? why all these ID fields, lets put all the data for a single item in a single row".

    Sounded wrong to me..but the man had a point. Our limitations now are more bandwidth oriented than space oriented.

    Why shouldnt we have everything in a single row. It simplifies our queries to something like
    select * from table
    as opposed to
    select table1.*, table2.field, table3.field from table1 join table 2 on ...etc

    Whats more, the first query is a lot more efficient. The flatter database structure will result in a larger datbase, but it should be a lot simpler and faster to manage.

    Now normalization does definately have a role, because if makes it a lot easier to manage large sets of data. So...should we not too both? So instead of using a traditional type of normalized structure:

    table1: (parent table)
    - p_ID
    - name

    table2: (child table)
    - ID
    - p_ID (fkey)
    - detail1
    - detail2
    - etc

    maybe something like:


    table1: (parent table)
    - p_ID
    - name

    table2: (child table)
    - ID
    - p_ID (fkey)
    - name
    - detail1
    - detail2
    - etc

    (so include the name field in the child table as well.)

    That way, to get all the information for table2 all we need to do is select * as opposed to having to join it to table1 to get the name field.

    The name field will be repeated in table2, wasting space..but otherwise the overall solution should be faster?

    I guess we may run into problems of data integrity, but these would have to be handled by your script. I guess that would be the downside of this approach...

    What do you think?

  2. #2
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,016
    Mentioned
    53 Post(s)
    Tagged
    2 Thread(s)
    yes, that would be the downside of the approach

    my suggestion is to let the project leader do his job and write pert and gannt charts, while you do your job and design the database properly

    if the project leader overrides your design, quietly register your disagreement in writing, and then carry on and try to make it work, and when the repercussions come tumbling home, they will pay you to deal with them, and you can mention how you said you shouldn't have done it that way in the first place
    r937.com | rudy.ca | Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  3. #3
    SitePoint Guru toasti's Avatar
    Join Date
    Feb 2004
    Location
    Grahamstown
    Posts
    634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    so i take it you are pro the relational approach?

  4. #4
    SQL Consultant gold trophysilver trophybronze trophy
    r937's Avatar
    Join Date
    Jul 2002
    Location
    Toronto, Canada
    Posts
    39,016
    Mentioned
    53 Post(s)
    Tagged
    2 Thread(s)
    yes, otherwise you mihgt as well use flat files to store your data
    r937.com | rudy.ca | Buy my SitePoint book: Simply SQL
    "giving out my real stuffs"

  5. #5
    SitePoint Guru toasti's Avatar
    Join Date
    Feb 2004
    Location
    Grahamstown
    Posts
    634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    lol! the man has a point!


Bookmarks

Posting Permissions

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