Results 1 to 6 of 6
  1. #1
    Join Date
    Jan 2004
    Posts
    1

    Unanswered: Relationship Database

    In this type of database is it feasible, efficient to have one master table that contains all of your information. From this master table other tables are fed columns and row.

    The master table would contain all information about a company.

    If not efficient why?

  2. #2
    Join Date
    Jan 2004
    Posts
    3

    Re: Relationship Database

    That doesn't sound efficient to me. When designing a relational database you must Normalize. Basically the idea is to eliminate redundant (repeating) data, and also for a generally smarter design (given the principles of a relational db).

    So if you have the same specific piece of data in your database twice, thats generally not a good thing.

    In conclusion, if I were you and wanting to address my db efficiency, I would research Normalization.

  3. #3
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713

    Re: Relationship Database

    Originally posted by jayx
    That doesn't sound efficient to me. When designing a relational database you must Normalize. Basically the idea is to eliminate redundant (repeating) data, and also for a generally smarter design (given the principles of a relational db).

    So if you have the same specific piece of data in your database twice, thats generally not a good thing.

    In conclusion, if I were you and wanting to address my db efficiency, I would research Normalization.
    Re: The 5 rules of data normalization ...

  4. #4
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Thanks for your reply. However, perhaps you can aid me further.
    I have spent along time working in a DB2 environment, writing queries etc, and
    have never heard of the following. I had a discussion with a web designer
    colleague of mine. He seems to think that a good database design would be to
    have all the data base info on one table. This would include customer name,
    address, supplier name and address, students name, and address, equipment needed
    for courses, employee names and addresses etc. I know in my years of working
    with databases that this would not really work. I mean, it is possible to have
    all this information on one table but how practical is it.

    If I had a column with only 5 rows for the number of employees and a column with
    500 rows for the number of suppliers, I would have 495 empty rows in the
    employee column. I have never designed a database and I am about to do so,
    however, I do not want to do some thing (input allot that of data) and then have
    to go back to the drawing board because it is not right.

    So I suppose I am asking, why would I not build one table with all and sundry in
    it? as I am struggling to give him an answer.

    Kind regards

    Danny
    Well Danny, All I can say is your colleague doesn't know much about relational database design ... You do not want (and Access only allows a MAX of 255 columns) to represent the data items you enumerated in a single table. It would not be workable for you to put employee, customer, suppier, student, and whatever else info into a single table ... How would you be able to relate data? You couldn't. You would have to replicate on each row the relating data (and obviously making it have no relation at all) ... Basically this degenerates into a glorified flat file system ... At that point you can legitimately say it is not a database.

  5. #5
    Join Date
    Dec 2003
    Location
    Texas
    Posts
    8
    Originally posted by M Owen
    Well Danny, All I can say is your colleague doesn't know much about relational database design ... You do not want (and Access only allows a MAX of 255 columns) to represent the data items you enumerated in a single table. It would not be workable for you to put employee, customer, suppier, student, and whatever else info into a single table ... How would you be able to relate data? You couldn't. You would have to replicate on each row the relating data (and obviously making it have no relation at all) ... Basically this degenerates into a glorified flat file system ... At that point you can legitimately say it is not a database.
    I agree with your point about having multiple tables. I am designing a financial database that feeds off of Sybase. I have created master queries (master query 1 = customer information, master query 2 = financial data) then create sub queries to accommodate specific report needs.

    I am not a dB admin but this seemed to make sense at that the time. Based on your experiences, is this the proper way to move forward?

    Thank you - Aj

  6. #6
    Join Date
    Sep 2003
    Location
    MI
    Posts
    3,713
    Originally posted by ajg68
    I agree with your point about having multiple tables. I am designing a financial database that feeds off of Sybase. I have created master queries (master query 1 = customer information, master query 2 = financial data) then create sub queries to accommodate specific report needs.

    I am not a dB admin but this seemed to make sense at that the time. Based on your experiences, is this the proper way to move forward?

    Thank you - Aj
    There's a difference between "creating views" which is in effect what you're doing and creating a relational database ... I have no idea on how your information is laid out in Sybase. Doing queries to pull info is fine and is how you get things done ... ADDING to the database is the crux of the matter tho ...

Posting Permissions

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