Creare nuove tabelle dinamicamente in base all'input dell'utente non è generalmente una buona idea. Se la struttura di base dei moduli cambia, tutte le tabelle create dinamicamente dovranno essere aggiornate per includere nuove colonne o rimuoverne di vecchie, e questo può causare mal di testa nella manutenzione. Poi c'è il problema di sapere quale tabella interrogare (che probabilmente porterà a SQL dinamico che apre tutti i nuovi problemi). E probabilmente ci sono anche problemi di prestazioni, ma non sono sicuro di quanto sarebbe male. Inoltre, una tabella viene solitamente utilizzata per rappresentare un tipo di entità (come "web form") piuttosto che avere copie della stessa tabella per ogni nuova istanza della stessa entità.
Suggerirei un solo tavolo per i moduli. Avrai bisogno di un identificativo su ciascun modulo per identificare di chi è il modulo:
forms
-----
id (PK)
name
owner_id (FK to users.id)
(other fields)
form_elements
-------------
id (PK)
form_id (FK to forms.id)
element_type_id (FK to element_types.id)
caption
(other fields)
element_types
-------------
id (PK)
name
element_list_values
-------------------
id (PK)
element_id (FK to form_elements.id)
name
value
(other fields??)
La tua applicazione web può consentire agli utenti di creare moduli che verranno salvati nelle tabelle forms
, con un riferimento all'utente che ha creato (supponendo che tu stia monitorando gli utenti come entità appropriate). Il modulo è popolato con form_elements
che fa riferimento alla tabella forms
in modo che sappiano a quale modulo appartengono e element_types
in modo che sappiano quale tipo sono. element_types
memorizzerà una lista (per lo più) statica di diversi elementi che un modulo può avere. I tipi potrebbero essere: "text_field", "drop_down_list", "radio_buttons", "checkbox". Per tipi come "drop_down_list" e "radio_buttons", avrai bisogno di una tabella aggiuntiva, chiamata forse element_list_values
per archiviare le opzioni possibili per gli elenchi che normalmente hanno questi elementi.