How to map user generated forms into a database? - forms

Question

I want users to be able to make forms with N fields, text, numbers, e-mail, combo, etc. How do i store each field without knowing how many of them will be?
The first way i thought of doing this is storing all the text fields in one table, all e-mail fields in another, etc. Then, in a table i store the form information with it's own ID.
How do i work around scalability in this form system? For example having multiple servers sharing forms.
Is my design good enough?
What do i need to store to transform then into html with XSLT?

Answer 1

Two solutions:
Create a clean, normalized database structure (avoid EAV Model)
Store meta data (like XML etc.) in the database
1. Solution:
forms table:
id | user_id | name
user_id: The "owner" of this form
name: The name of the form like "Registration" or whatever
form_fields table:
id | form_id | label | type | sorting | values | default
form_id is a foreign key to the forms table
label is the Label for the input like "Password"
type is the input type (like select, email, password, text), based on this you can handle the displaying / validation etc.
sorting gives you the ability to arrange fields in a form
values - predefined values example is a select box, store this as meta data like xml,json or whatever and parse it in your application, you can use the type field to determine how you want to handle these values
default - a default value (maybe a selected value in a select box or pre-defined text for a text input)
if someone fills out a form:
filled_forms table:
id | user_id | form_id
user_id: who filled the form?
form_id: which form?
filled_form_values:
id | filled_form_id | field_id | values
filled_form_id: foreign key to filled_forms table
field_id: the field id of the form
values: the entered values, maybe store as metadata like JSON, XML (example: a select box which allows multiple selections) you can join the form and the form field so you get the type of the field and then you can handle the values properly
Pros:
The database handles data integrity for you
Normalized database schema
Cons:
Static schema, multiple joins to retrieve fields
Goes in the direction of a EAV-Model
No direct transformation with XSLT possible
2. Solution:
You have only two tables:
forms table:
id | user_id | name | metadata
user_id: Owner of the form (foreign key)
name: Name of the form (like Registration etc.)
metadata: Your self-implemented description of the form (HTML,XML,JSON whatever) which describes the form properly, giving IDs to the elements etc.
filled_forms table:
id | form_id | user_id | values
form_id: Foreign-Key to the form
user_id: Foreign-Key to the user who filled out the form
values: Your self-implemented description of the filled out form (HTML, XML, JSON whatever) which describes the input and maps it to the fields correctly
Pros:
Very flexible, no EAV trap, simple structure
Direct transformation with XSLT possible
Cons:
You have to ensure data integrity by your own