Problem solve Get help with specific problems with your technologies, process and projects.

Database design for Web page search function

I need help with the design of my database! I'm gonna use it for my Web page as a search function, and it shall include the following:

  • Membership Number = Denmark-girl-1 ("Country"-"Sex"-"Member no.")
  • Membership Status = Yes/No
  • Membership Date = 17 May 2001
  • Sex = Female/Male
  • Sexual Orientation = Hetrosexual / Bisexual
  • Age = ???
  • Nickname = ???
  • Firstname = ???
  • Lastname = ???
  • City = ???
  • Postal Code = ???
  • Country = ???
  • E-mail-adress = ???
  • Phone Number = ???
  • Cellphone = ???
  • Profile = Fresh girl from Copenhagen....
  • Bodyfigure = Slim / Normal / Robust / Butter / Overweight / Handicapped
  • Height = ??? cm.
  • Weight = ??? Kg.
  • Hip = ? cm.
  • Waist = ? cm.
  • Bosom = ? cm.
  • Eyecolor = Blue / Green / Brown / Black / Other
  • Shoe Size = 34-50
  • Haircolor = White / Red / Brown / Black / Other
  • Pubic hair = Yes / No
  • Piercings = Yes / No (In Ear / In Nose / In Lip )
  • Tatoos = Yes /No
  • Smoking = Yes / No
  • Updated = 17 May 2001
  • <

    Your basic design should be pretty simple. You can go from something completely application driven where all of the logic is built into every program/routine that will access this data, to something that is almost completely data driven. I'd recommend using the data driven approach, since it makes it much easier to maintain your data later.

    Your membership number is what is called a compound column. This is where a single logical column in your database is composed of more than one logical part. While it is perfectly all right to display data this way, storing it this way is an accident waiting to happen! If you make three separate columns to hold the data, then combine them for the purpose of display, it will avoid lots of potential problems.

    The bodyfigure, eyecolor, and haircolor columns are cases where I would strongly recommend a foreign key. I'd create a lookup table of bodyfigures, then add a foreign key relationship into your main table, and do the same with eyecolors and haircolors.

    The piercings column looks like a combination of a Boolean (yes/no) with a list type. This would lead to some really tough problems in the code, but there is a relatively clean way out if you construct the list carefully. I'd build the list like:

    PieceId Description
    0 None
    1 Ear
    2 Nose
    3 Ear and Nose
    4 Lip
    5 Ear and Lip
    6 Nose and Lip
    7 Ear, Nose, and Lip

    The trick here is that the id values are basically a bitmap. If you think of them as binary numbers, there are three columns (1, 2, and 4). A binary one in a column means that the appropriate body part has been pierced.

    The sex and orientation columns are a judgment call. You could create a constraint for the column, limiting it to one of the two values you've specified, but based on some of your examples this could be limiting for no good reason. You might want to add additional sex options (transgendered or surgically altered for examples), and different orientations (sorry, you'll have better luck thinking of alternatives here than I would, but I'm sure there are plenty). I'd use a foreign key and a lookup table for these columns too.

    As a side note, I'd strongly suggest that you add an identity column too. It is MUCH easier and more efficient to write code using a single id for a member than trying to manage multi-part keys!

    I noticed that you posted this question in the discussion forum too. Feel free to post further questions there (I'd love the feedback)!

    For More Information

    Dig Deeper on Oracle database design and architecture

    Have a question for an expert?

    Please add a title for your question

    Get answers from a TechTarget expert on whatever's puzzling you.

    You will be able to add details on the next page.

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.