4 replies to this topic

[lethalwire]

Let's say I have several types of html forms that can be filled out and the data is saved to a database.
Now what I'm trying to figure out is how can I store the form's "metadata(excuse me if needed for incorrect terminology)" in the database?

For example, I have a form that has a text field[name], a checkbox area[skills], and a radio button area[hair color].
So I have a table that stores the data (that the user submitted) from the form textfield, checkbox area, and radio button area.
How can I design a table that would show that the name input is a text field, the skills input is a checkbox, and hair color input is a radio button?

I was thinking a design of something similar to:

Table 1

------------------------------

|              form          |

------------------------------

|name |skills    |hair_color |

------------------------------

|data  |data    |data        |

------------------------------

|data  |data    |data        |

------------------------------

|data  |data    |data        |

------------------------------

|data  |data    |data        |

------------------------------



Table 2

------------------------------

|      form_metadata         |

------------------------------

|name |skills    |hair_color |

------------------------------

textF |checkB    |radioB     |

------------------------------

I'm not sure if this would be a feasible approach to this problem and would like a push in the right direction.

[lespauled]

If I understand this correctly, you will need several tables.

1- control types
2- control options (for dropdowns, etc.)
3- controls that are on the page (display order, type, etc.)
4- Storing the data in a values table.
5- Data Types

[Orjan]

I see no point in using table 1 and 5 in your example. If it's used with php, just use a varchar to store any type of value in it. Vertical storage is probably the best way to fix this.

[lethalwire]

Vertical storage? I've never heard of this before.

Would a table even be feasible for this? Should I instead use something like xml to inform php that input 1 is a textbox, input 2 is a checkbox, input 3 is a radio button, etc.?
I'm just beginning work with databases so I'm taking in a lot of information at once(not purposely!).

The reason why I'm leaning against the idea of a table is that it seems like a waste of a table that will have only 1 row of data about 1 form.

So instead, I might give you a general idea about the problem I'm facing.
I have to take many physical forms and digitize them and store the data into the database. I wanted to create a CMS that can update/add/remove the forms.
With this I wanted PHP to pull form data from the database but also pull metadata about the forms so php can generate the forms.

I'm beginning to think this idea might be overkill. I'm now thinking that I should generate the php/html page for each form and store it on the server.
Example:

Directory...

Folder 1

....Form1.html.php

....Form2.html.php

....Subfolder

........Form1a.html.php

........Form2a.html.php

...etc

[Orjan]

Vertical storage means that you have few columns and many rows in your table, normally three columns, one scope, one name and one data.
Example as for you:

Scope | name | data
myform | nameField | text
myform | skills | checkbox
myform | hair_color | radio

With this, you can have all forms in one table, just to filter on scope.
this is also a good way of storing configuration variables etc.

---------- Post added 01-26-2012 at 12:14 AM ---------- Previous post was 01-25-2012 at 11:46 PM ----------

I wrote a tutorial using vertical storage some time ago...
http://forum.codecal...parameters.html