Eu tenho um aplicativo que permite aos usuários criar formulários diferentes (pesquisas) e preenchê-los. (por isso é um substituto para o papel).

Aqui está o modelo atual que estou usando no aplicativo:

 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 |
+----+---------------------------------+

Então, basicamente, quando um usuário cria uma pesquisa, os programas inserem um registro na Tabela de pesquisas e depois criam 2 tabelas:

tabela (2) para os campos da tabela de formulário (3) para os registros que serão lojas, nas quais as colunas correspondem às linhas da tabela (2).

Funciona, mas tem algumas limitações. Por exemplo, quando você deseja adicionar um campo à tabela (2), ele deve ler o conteúdo da tabela (3), salvá-lo em uma tabela virtual, soltar a tabela anterior (3) e criar uma nova. Isso pode ser um problema de desempenho quando a tabela (3) possui muitos registros.

Então, minha pergunta é ... Existe um design de banco de dados melhor?