Tạo các bảng mới một cách linh hoạt dựa trên đầu vào của người dùng thường không phải là một ý tưởng tốt. Nếu cấu trúc cơ bản của biểu mẫu thay đổi, tất cả các bảng được tạo động sẽ cần được cập nhật để bao gồm các cột mới hoặc loại bỏ các cột cũ và điều này có thể gây ra đau đầu bảo trì. Sau đó, có vấn đề về việc biết bảng nào sẽ truy vấn (có thể sẽ dẫn đến SQL động mở ra tất cả các vấn đề mới). Và có lẽ cũng có vấn đề về hiệu suất, nhưng tôi không chắc điều đó sẽ tệ đến mức nào. Ngoài ra, một bảng thường được sử dụng để đại diện cho một loại thực thể (chẳng hạn như "mẫu web") thay vì phải bản sao của cùng một bảng cho mỗi mới dụ của cùng một thực thể.
Tôi muốn đề xuất một bảng duy nhất cho các hình thức. Bạn sẽ cần một mã định danh trên mỗi biểu mẫu để xác định biểu mẫu đó là:
các hình thức
-----
id (PK)
Tên
own_id (FK cho người dùng.id)
(các lĩnh vực khác)
form_elements
-------------
id (PK)
form_id (FK đến Forms.id)
Element_type_id (FK đến Element_types.id)
chú thích
(các lĩnh vực khác)
phần tử
-------------
id (PK)
Tên
phần tử_list_values
-------------------
id (PK)
Element_id (FK đến form_elements.id)
Tên
giá trị
(các lĩnh vực khác??)
Ứng dụng web của bạn có thể cho phép người dùng tạo các biểu mẫu sẽ được lưu trong các formsbảng, với tham chiếu đến người dùng đã tạo (giả sử rằng bạn đang theo dõi người dùng dưới dạng thực thể phù hợp). Biểu mẫu được điền với form_elementstham chiếu formsbảng đó để họ biết họ thuộc về biểu mẫu nào và element_typesvì vậy họ biết họ thuộc loại nào. element_typessẽ lưu trữ một danh sách tĩnh (hầu hết) các yếu tố khác nhau mà một hình thức có thể có. Các loại có thể là: "text_field", "drop_down_list", "radio_buttons", "hộp kiểm". Đối với các loại như "drop_down_list" và "radio_buttons", bạn sẽ cần một bảng phụ, có thể được gọi element_list_valuesđể lưu trữ các tùy chọn có thể có cho các danh sách mà các thành phần này thường có.