Dinamik olarak kullanıcı girişine dayalı yeni tablolar oluşturmak genellikle iyi bir fikir değildir. Formların temel yapısı değişirse, dinamik olarak oluşturulan tüm tabloların yeni sütunlar içerecek şekilde güncellenmesi veya eskileri kaldırması gerekir; bu da bakım baş ağrısına neden olabilir. Sonra hangi tablonun sorgulanacağını bilme sorunu var (bu muhtemelen tüm yeni problemleri açan dinamik SQL'e yol açacaktır). Ve muhtemelen performans problemleri de var, ama bunun ne kadar kötü olacağından emin değilim. Ayrıca, bir tablo genellikle aynı varlığın her yeni örneği için aynı tablonun kopyalarını almak yerine bir tür varlığı ("web formu" gibi) temsil etmek için kullanılır .
Formlar için tek bir masa öneririm. Hangi formda olduğunu tanımlamak için her formdaki bir tanımlayıcıya ihtiyacınız olacak:
formlar
-----
kimliği (PK)
isim
owner_id (Kullanıcılar için FK)
(diğer alanlar)
form_elements
-------------
kimliği (PK)
form_id (FK for forms.id)
element_type_id (element_types.id için FK)
altyazı
(diğer alanlar)
element_types
-------------
kimliği (PK)
isim
element_list_values
-------------------
kimliği (PK)
element_id (form_elements.id için FK)
isim
değer
(diğer alanlar ??)
Web uygulamanız, kullanıcıların oluşturdukları kullanıcıya formsatıfta bulunarak (kullanıcıları uygun varlıklar olarak takip ettiğiniz varsayılarak) tablolara kaydedilecek formlar oluşturmalarına izin verebilir . Form form_elementsbu referans ile doldurulur, formsböylece hangi forma ait element_typesolduklarını bilirler ve böylece hangi tip olduklarını bilirler. element_typesBir formun sahip olabileceği farklı öğelerin statik (çoğunlukla) bir listesini depolar. Tipler şunlar olabilir: "text_field", "drop_down_list", "radio_buttons", "checkbox". "Drop_down_list" ve "radio_buttons" gibi türler element_list_valuesiçin, bu öğelerin normalde sahip olduğu listeler için olası seçenekleri depolamak için belki de denen fazladan bir tabloya ihtiyacınız olacaktır.