I've a credit card applicatoin that allows customers create variations (surveys) after which fill them. (so its an alternative to paper).

Here's the present model i am using within the application:

 Table 1)
+-------------------------+
|      SURVEYS TABLE      |   
+----+------+-------------+
| ID | name | description |  
+----+------+-------------+

 Table 2)   
+-----------------------------------+
|       $[name_of_the_survey]       |
+----+-------+------+-------+-------+
| ID | field | type | value | items |
+----+-------+------+-------+-------+


 Table 3)
+--------------------------------------+
|    $[name_of_the_survey] _records    |
+----+---------------------------------+
| ID | columns specific to each survey |
+----+---------------------------------+

so essentially whenever a user produces market research, the programs card inserts an archive in Surveys Table after which produces 2 tables:

table (2) for that fields from the form table (3) for that records that'll be stores, where the posts match table (2) rows.

It really works but has some restrictions. For example, whenever you which to include a area to table (2), it needs to read table (3) contents, save it to some virtual table, drop previous table (3) and make up a brand new one. This is often a performance problem once the table(3) provides extensive records.

So my real question is... It is possible to better database design?

Utilizing a separate table for every survey nearly invalidates using a database. You may as well just keep leads to files.

You need to do, however, need three tables: Survey Definition, Survey Questions, and Survey Solutions. It might look something similar to this...

Surveys:
ID; name; description

Questions:
ID; text; surveyID

Answers:
ID; answer; questionID

You could include complexity after that to deal with enumerated solutions...

Surveys:
ID; name; description

Questions:
ID; text; surveyID

Choices:
ID; choice; questionID

Answers:
ID; choiceID

You apply the associations in between each table to aggregate to another greatest level, permitting you to definitely get is a result of any question, survey, or other characteristics for just about any model you decide to add without attempting to abstract away the origin for the choose claims. This enables you to definitely aggregate solutions per user or surveying organization afterwards after adding these to your schema. If each survey features its own table structure, aggregating data across surveys becomes greatly not practical as the application develops.

You could try considering http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

The above mentioned is a reasonably formal method of enhancing DBs generally, and a few of the steps are highly relevant to your DB. I believe it's a little confusing with the ID fields. Do you want them for every one? Are survey names not unique?

You've implied the survey data fields are very unique. Personally I'd sort put each survey right into a file, and merely provide a typical format. It is not an awful idea when the inclination would be to read a whole survey at the same time. I'd just use a DB basically required to sort or select items of data.