Table structure?!?

Greetings

I'm developing an intranet-based system for filing sampling journals.

I have 6 different types (which may get more later) of samples which need different forms. Partially these forms contain parts which may be taken for all different types of samples, for example the header with positional data and so on.
Now the current way I'm doing it is that I have a totally modular system. I split up the forms, write the code and put them into a DB named form_parts. It's set up like this:

form_parts
formpart_id
show_form
add_form
add_sql
...

Next DB I have is sample_type which connects the samples with the proper form-parts.

My question now is: How do I choose the right DB-stucture for the sample data?

1. I may continue the modular way: 1 table per form-part (the way I'm doing it ATM), which ends up in a whole lot of tables (approx. 8 parts per form x 6 samples = 32 tables) which results in a whole lot of chaos Pro of this way is that I may add more sample types later easily

2. One table per sample type: Much less tables, but double structure for e.g. the header

3. One for all, all in one: I could put everything into one table. Would make life easy. Not needed columns would be filled with Null-Values. Proper output would still be given due to the "show_form" parts, which pick out the proper parts

Which of this 3 would you choose or do you know any better solution?

Try using one table with 2 fields.

The first field is your primary key like an integer value or uniqiue name.

The second field of type longtext is a seperated string containing ur form information.

For example:

header=header_value&field1=field1_value

Then use parse_str() method which will assign all the values to the relevant variables as follows :

$header = 'header_value';

And then dynamically build your form passed on teh variable values.

Thx man, good idea.
I think it also solves the 2nd problem I encountered. If I'd put everything into one table, it'd have about 50 cloumns or sth... Not quite good I'd say.