I’ve got a product I’m redesigning.
The old db design was …
ID, Key, Value, all strings, where the value could be a number, text, or a date. Trying to do type specific searches on this data was impossible(or slow enough that it didn’t matter). Key is a set of values that an object has, so say obj a has a birthdate of 1/12/1969, name of Dan, and phoneNumber of 555-555-5555, i nthe database this was stored as
a birthdate 1/12/1969
a name Dan
a phonenumber 555-555-5555
I want to redesign it so that the keys are actually fields so we would have this
a 1/12/1969 Dan 555-555-5555
The worry I have is that when the user goes in and adds a new Key, say cellphone, that adding the column could take a long time and/or be confusing to the user.
The users will most likely define the keys at the beginning, but there is a chance that a key gets added after years of using the product.
One thought I had was adding several columns of the different types we support to the table as empty and then renaming them as a user would add them, yes, I would still have the problem when I run out of these empty columns, but most of my users would never see this. I don’t like this answer, but I like the alter table scenario somewhat less.
Anyone have any thoughts or ideas?
Finally, this is a product where the database backend can be oracle, sql server, or access(probably not, but maybe)
What you’re describing is called Entity Attribute Value. Modeling something like this is difficult and any solution you decide on will probably have at least some disadvantages. You should take a look at this stackoverflow question that has a pretty comprehensive discussion on the topic:
Entity Attribute Value Database vs. strict Relational Model Ecommerce