Reputation: 1
Picture a web service that lets a user construct several different kinds of custom-made web forms and then fills multiple instances of each form with different values.
For example, make a form named "movies I have watched" with fields such as "genre", "year" "director" etc. and another form "books that I have read" with fields such as "author", "pages" etc. and then register a lot of movies and books in my profile.
I am trying to figure out how the DB for this service should be organized for maximum versatility:
The most obvious way that I thought of is to have a separate table for every new form that is created, but that looks like it might be slow, and tedious to program.
Another approach is to limit the number of fields that a user can insert, and create one table that holds all "forms" and has columns such as "Custom_value_1", "Custom_value_2", etc. (I will have to store the label and data type of each value in another table).
Haven't thought of it yet :)
Upvotes: 0
Views: 160
Reputation: 50990
You are considering the difference between building a domain-specific relational database and a key-value model system. You can look those terms up to learn more about them.
The key-value system is more flexible, but difficult to program. The relational model requires you to correctly model each kind of "thing" that you might want to put in the database, which is less flexible but much, much easier to program (since you can pretty much build the forms from introspecting the data model).
In this case, it sounds like neither is really the best solution for you. I'd look into some more flexible document type storage. In particular, this sounds like it might be a good job for XML or an XML oriented database.
Upvotes: 1