Requires Free Membership to View
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
- What do you think about this answer? E-mail us at editor@searchDatabase.com with your feedback.
- The Best Database Design Web Links: tips, tutorials, scripts, and more.
- Have a Database Design tip to offer your fellow DBA's and developers? The best tips submitted will receive a cool prize--submit your tip today!
- Ask your technical Database Design questions--or help out your peers by answering them--in our live discussion forums.
- Ask the Experts yourself: Our Database Design guru is waiting to answer your toughest questions.
This was first published in May 2001
Join the conversationComment
Share
Comments
Results
Contribute to the conversation