Results 1 to 4 of 4

Thread: Database design

  1. #1
    Join Date
    Dec 2009
    Posts
    7

    Unanswered: Database design

    Hi,

    This i posted in stackoverflow, i am also looking for replies from your forum also,

    i have fieldnames, f1, f2, f3, f4, f5, f6. These field names are to be shown depending on the values of other field names.

    Example, f3 has to be shown, if f2 value is "COND1" f4 has to be shown, if f3 value is "COND

    the field names are not fixed, they can be added, edited and deleted. The values COND1, COND etc are also not fixed, they can be changed.

    Can someone point how to design the database


    Thanks

  2. #2
    Join Date
    Apr 2002
    Location
    Toronto, Canada
    Posts
    20,002
    Quote Originally Posted by shivam0101 View Post
    This i posted in stackoverflow, i am also looking for replies from your forum also,
    let's see if stackoverflow is as honest with you as i'm going to be...


    Quote Originally Posted by shivam0101 View Post
    i have fieldnames, f1, f2, f3, f4, f5, f6.
    that's a crap design right there

    you should give the columns real names


    Quote Originally Posted by shivam0101 View Post
    the field names are not fixed, they can be added, edited and deleted.
    that's a ~really~ crap design there

    column names should stay fixed forever



    Quote Originally Posted by shivam0101 View Post
    Can someone point how to design the database
    scrap what you have and start over

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

  3. #3
    Join Date
    Sep 2009
    Location
    San Sebastian, Spain
    Posts
    880
    As Rudy has said the design is not optimal. You need to look more closely at what is happening. For instance, when you say f3 has to be shown where f2 is 'COND' what should be displayed when f3 is not 'COND'? Do you really need to store the information if f3 is not 'COND'?

    If you are going to have variable number of columns with renaming, this is bad, however, if you view this differently and allow the data to grow in terms of rows rather than columns this will make expanding and reducing the pieces of information that you are gathering easier in the long term.

    For instance, let's imagine we need to store information for a client, we could have a table with clientid, attributeType, attributeValue. If there is only 1 piece of information for a client to be stored or 100 pieces of information the design remains the same.
    Ronan Cashell
    Certified Oracle DBA/Certified MySQL Expert (DBA & Cluster DBA)
    http://www.it-iss.com
    Follow me on Twitter

  4. #4
    Join Date
    Oct 2009
    Location
    221B Baker St.
    Posts
    486
    Maybe if you post the actual requirement you will get more useful replies. . .

    It appears you have asked for a model that will do anything/everything with no (or very little) definition. . .

Posting Permissions

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