A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am trying to come up with a solution to the following design problem. I am trying to keep track of some items which have some common attributes. I am using a database to keep track of the items and the columns in the table are the attributes. The problem is that one of the attributes is such that it could have more than one entry and you don't know up front how many entries there will be for that attribute.
Example: let's say the items are fruits; and we are keeping track of the following attributes: weight, color, taste. Let's say that weight and color are single entries, while taste could be multiple entries such as "sweet" and "mild".
What I initially thought I could do is keep the "taste" attribute as a single column in the database, and store the multiple entries as a single entry by joining them with a delimiter character. This would work except it just doesn't sound very elegant. Plus, it is harder to manipulate in the code.
The other thing I thought about was creating a unique "taste attribute" table for each item. This table will have all the taste attribute entries. It can be as big or small as it needs to be. Again, this would work, but this solution doesn't sound too elegant either.
If you've faced a design problem like this, and solved it in ways different than what I came up with, I am all ears.
I am open to suggestions.
Saturday, August 12, 2006
I am a novice when it comes to database design. It looks like "database normalization" was the terminology I needed to use to google this issue.
Sunday, August 13, 2006
Yes, the "relation" in RDBMS refers to the fact that you can link (join) multiple tables.
If you need an example, just ask. But I'm shure you'll find something with google. Maybe read an intro book on sql, too.
Monday, August 14, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz