नए इनपुट को गतिशील रूप से उपयोगकर्ता इनपुट के आधार पर बनाना आमतौर पर एक अच्छा विचार नहीं है। यदि प्रपत्रों की मूल संरचना में परिवर्तन होता है, तो सभी गतिशील रूप से बनाए गए तालिकाओं को नए कॉलमों को शामिल करने के लिए अद्यतन करना होगा या पुराने हटा दिए जाएंगे, और इससे रखरखाव सिरदर्द हो सकता है। फिर यह जानने की समस्या है कि किस तालिका से क्वेरी (जो संभवतः गतिशील एसक्यूएल का नेतृत्व करेगी जो सभी नई समस्याओं को खोलती है)। और शायद प्रदर्शन की समस्याएं भी हैं, लेकिन मैं निश्चित नहीं हूं कि यह कितना बुरा होगा। इसके अलावा, एक तालिका का उपयोग आमतौर पर एक ही इकाई के प्रत्येक नए उदाहरण के लिए एक ही तालिका की प्रतियां होने के बजाय एक प्रकार की इकाई (जैसे "वेब फ़ॉर्म") का प्रतिनिधित्व करने के लिए किया जाता है ।
मैं प्रपत्रों के लिए एक एकल तालिका सुझाता हूँ। आपको पहचानने के लिए प्रत्येक फॉर्म पर एक पहचानकर्ता की आवश्यकता होगी कि यह किसका है:
रूपों
-----
आईडी (पीके)
नाम
owner_id (users.id पर FK)
(अन्य क्षेत्र)
form_elements
-------------
आईडी (पीके)
form_id (FK to forms.id)
element_type_id (FK to element_types.id)
शीर्षक
(अन्य क्षेत्र)
element_types
-------------
आईडी (पीके)
नाम
element_list_values
-------------------
आईडी (पीके)
एलिमेंट_आईडी (FK to 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कि इन सूचियों के लिए संभावित विकल्पों को संग्रहीत करने के लिए कहा जाए जो इन तत्वों के पास सामान्य रूप से हैं।