Створення нових таблиць динамічно на основі введення користувача зазвичай не є хорошою ідеєю. Якщо основна структура форм зміниться, всі динамічно створені таблиці потрібно буде оновити, щоб вони включали нові стовпці або видаляли старі, і це може спричинити головний біль у обслуговуванні. Тоді виникає проблема знати, до якої таблиці слід запитувати (що, ймовірно, призведе до динамічного SQL, який відкриє всі нові проблеми). І, мабуть, є і проблеми з роботою, але я не впевнений, наскільки це було б погано. Також таблиця зазвичай використовується для представлення типу сутності (наприклад, "веб-форма"), а не для копіювання тієї ж таблиці для кожного нового примірника того ж об'єкта.
Я б запропонував єдину таблицю для бланків. Вам знадобиться ідентифікатор для кожної форми, щоб визначити, чия форма це:
форми
-----
ідентифікатор (ПК)
назва
owner_id (FK для користувачів.id)
(інші поля)
form_elements
-------------
ідентифікатор (ПК)
form_id (від FK до form.id)
element_type_id (від FK до element_types.id)
підпис
(інші поля)
елементи_типів
-------------
ідентифікатор (ПК)
назва
element_list_values
-------------------
ідентифікатор (ПК)
element_id (від FK до form_elements.id)
назва
значення
(інші поля ??)
Ваша веб-програма може дозволити користувачам створювати форми, які будуть збережені в formsтаблицях, з посиланням на користувача, який створив (якщо припустити, що ви відстежуєте користувачів як належні сутності). Форма заповнена form_elementsцією formsтаблицею, щоб вони знали, до якої форми вони належать, і element_typesтому вони знають, до якого типу вони є. element_typesбуде зберігати статичний (в основному) список різних елементів, які форма може мати. Типи можуть бути: "text_field", "drop_down_list", "radio_buttons", "checkbox". Для таких типів, як "drop_down_list" та "radio_buttons", вам знадобиться додаткова таблиця, можливо, покликана element_list_valuesдля зберігання можливих параметрів списків, які зазвичай мають ці елементи.