Say your users can create their own web-based forms (textboxes, selects, etc) and publish them on the web for their users to fill out.
Does anyone have a resource or any advice on how to architect the database to tie into the dynamic forms?
For example, would you create a child table for each form, or different versions of a given form?
Creating new tables dynamically based on user input is usually not a good idea. If the basic structure of forms changes, all the dynamically created tables will need to be updated to include new columns or have old ones removed, and this can cause maintenance headaches. Then there's problem of knowing which table to query (which will probably lead to dynamic SQL which opens up all new problems). And there's probably performance problems too, but I'm not certain how bad that would be. Also, a table is usually used to represent a type of entity (such as "web form") rather than having copies of the same table for each new instance of the same entity.
I'd suggest a single table for the forms. You'll need an identifier on each form to identify whose form it is:
forms ----- id (PK) name owner_id (FK to users.id) (other fields) form_elements ------------- id (PK) form_id (FK to forms.id) element_type_id (FK to element_types.id) caption (other fields) element_types ------------- id (PK) name element_list_values ------------------- id (PK) element_id (FK to form_elements.id) name value (other fields??)
Your web application can let users create forms which will be saved in the forms tables, with a reference to the user that created (assuming that you are tracking users as proper entities). The form is populated with form_elements that reference the forms table so they know which form they belong to, and the element_types so they know which type they are. element_types will store a static (mostly) list of different elements a form can have. Types could be: "text_field", "drop_down_list", "radio_buttons", "checkbox". For types such as "drop_down_list" and "radio_buttons", you'll need an extra table, maybe called element_list_values to store the possible options for the lists that these elements normally have.
