एक संबंधपरक डेटाबेस में क्लाइंट रचनात्मक और संशोधित वेब फ़ॉर्म का सबसे अच्छा कार्यान्वयन क्या है?

Question

कई वेब एप्लिकेशन प्रोजेक्ट्स में मैं एक हिस्सा रहा हूं, क्लाइंट अपने स्वयं के फॉर्म बनाने में सक्षम होने के लिए कहता है। सवाल उठता है कि उनकी फॉर्म परिभाषाओं को कैसे स्टोर किया जाए, और फिर उपयोगकर्ता इनपुट मानों को उन कस्टम रूपों में कैसे स्टोर किया जाए।

मैं इसे दो तरीके से किया देखा है:

1. यह मानते हुए कि ग्राहक केवल क्या लेबल उन क्षेत्रों के साथ जुड़े रहे हैं कि कितने क्षेत्र, और परिभाषित करता है; हम चार तालिकाओं से जुड़े समाधान में आ सकते हैं। FormDefinition, FormFieldDefinition, FormInstances, FormFieldValues। ग्राहक FormDefinition और FormFieldDefinition में परिवर्तन करता है, और वेब ऐप उस जानकारी का उपयोग HTML वेब फ़ॉर्म प्रस्तुत करने के लिए करता है, जिस पर वेबसाइट विज़िटर (अंतिम उपयोगकर्ता) फॉर्म सबमिट करेगा, जिसमें FormInstances में एक नई पंक्ति बनाई गई है और मान हैं FormFieldValues तालिका में सहेजा गया। FormDefinition में

   पंक्तियाँ रूप है, अर्थात form definition ID = 2, form title = 'Car Registration Form' परिभाषित करता है। FormFieldDefinitionFormDefinition, यानी field definition ID = 7, field label = 'Car Model', field type = 'varchar(50)' में किसी फ़ॉर्म के फ़ील्ड को परिभाषित करता है। FormInstance में पंक्तियां उपयोगकर्ता द्वारा भरे प्रत्येक फॉर्म का उदाहरण है, यानी definition id = 2, date_entered = '2008-09-24'। और FormFieldValues में पंक्तियां उपयोगकर्ता द्वारा प्रविष्टियां हैं, यानी field definition = 7, value = 'Tiburon'।

   दुर्भाग्य से, इसका मतलब है FormFieldValues में मूल्य स्तंभ सबसे बड़ा संभव आकार है कि आपके ग्राहक वेब फ़ॉर्म में निर्दिष्ट कर सकता है की एक चार प्रकार होना चाहिए ... और जब प्रपत्र परिभाषाएँ बदलने से पुराना डेटा के प्रबंधन iffy हो जाता है। लेकिन उपयोगकर्ता प्रविष्टियां क्वेरी करने योग्य हैं (मैंने quick query लिखा है जो एक उपयोगकर्ता आईडी प्रविष्टियों को सूचीबद्ध करता है जो another pivot question के समान है)।

2. चार टेबल का उपयोग करने का एक विकल्प फॉर्म परिभाषाओं और उपयोगकर्ता की फॉर्म प्रविष्टियों को एक्सएमएल (या वाईएएमएल या कुछ समान) में क्रमबद्ध करना होगा और टेक्स्ट के रूप में स्टोर करना होगा। उल्टा यह है कि रूप डेटाबेस में मानव पठनीय हैं। नकारात्मकता यह है कि एक्सएमएल पार्सिंग के साथ अधिक एप्लिकेशन ओवरहेड होगा, और डेटाबेस एसक्यूएल स्टैंडपॉइंट से बहुत कम पूछताछ योग्य हो जाता है।

मेरा असली सवाल यह है कि, इस डेटाबेस मॉडल को क्या कहा जाता है? (इसलिए मैं इस समस्या को Google पर डाल सकता हूं।) लेकिन मैं इसका जवाब दूंगा: कौन सा बेहतर कार्यान्वयन है या वहां बेहतर (या उतना ही अच्छा) कार्यान्वयन है?

Answer 1

जो आप वर्णन कर रहे हैं उसे अक्सर "एंटिटी-एट्रिब्यूट-वैल्यू" कहा जाता है, और कभी-कभी "मिश्रण डेटा और मेटाडेटा" के रूप में वर्णित किया जाता है। यही है, गुणों (फ़ील्ड) के नाम स्ट्रिंग्स (डेटा) के रूप में संग्रहीत हैं।

इससे जटिल समस्याओं का एक गुच्छा होता है जैसे यह सुनिश्चित करना कि प्रत्येक फॉर्म इंस्टेंस में फ़ील्ड का एक ही सेट शामिल है, या सुनिश्चित करना अनिवार्य फ़ील्ड भर चुके हैं (पारंपरिक तालिका में न्यूल के बराबर नहीं)।

आपने पूछा कि एक रिलेशनल डेटाबेस के साथ यह कैसे करना है। एक संबंधपरक डेटाबेस में, आपको मेटाडेटा के लिए मेटाडेटा का उपयोग करना चाहिए। इस मामले में, इसका मतलब है प्रत्येक फॉर्म के लिए नई तालिका बनाना, और फॉर्म फ़ील्ड के लिए कॉलम का उपयोग करना। तो आपकी फॉर्म परिभाषा केवल टेबल मेटाडेटा है, और उस तालिका में एक फॉर्म इंस्टेंस एक पंक्ति है। यदि आप बहु-मूल्यवान उत्तरों (जैसे चेकबॉक्स) के साथ फ़ॉर्म का समर्थन करते हैं, तो आपको निर्भर टेबल भी चाहिए।

यह महंगा या कठिन पैमाने पर लग सकता है। शायद सही। इसलिए एक रिलेशनल डेटाबेस इस नौकरी के लिए सबसे अच्छा उपकरण नहीं हो सकता है। आपने एक्सएमएल या वाईएएमएल की संभावना का उल्लेख किया है; मूल रूप से किसी प्रकार का संरचित फ़ाइल प्रारूप जिसे आप विज्ञापन को परिभाषित कर सकते हैं। आपको प्रत्येक ग्राहक के फॉर्म के लिए डीटीडी परिभाषित करना चाहिए, इसलिए एकत्र किए गए प्रत्येक फॉर्म को सत्यापित किया जा सकता है।

संपादित करें: तुम सच में अपने आवेदन में EAV के लचीलेपन की जरूरत है, यह ठीक है, वहां आम तौर पर परिस्थितियों है कि नियमों को तोड़ने का औचित्य साबित कर रहे हैं। बस उस अतिरिक्त कार्य के बारे में जागरूक रहें, और इसके विकास कार्यक्रम में इसके लिए योजना बनाएं और जब आप लोड को संभालने के लिए अपने सर्वर को स्केल करते हैं। StackOverflow पर एक और answer of mine about EAV भी देखें।

Answer 2

इस डेटाबेस मॉडल को क्या कहा जाता है?

सुनिश्चित नहीं है कि वास्तव में इसे क्या कहना है, लेकिन यह वही प्रक्रिया है जो गतिशील रूप से सर्वेक्षण उत्पन्न करती है। यदि आप सर्वेक्षण अनुप्रयोगों को उत्पन्न करने के लिए किसी भी स्रोत की तलाश करते हैं तो आपको समान सामान्य डेटाबेस स्कीमा के साथ-साथ समान विधियां भी मिलेंगी।

यूआई विचारों के लिए http://wufoo.com/ या http://frevvo.com/ जैसे फॉर्म बिल्डर साइट्स में भी देखें (यदि आप इसे वेब आधारित बना रहे हैं)।

Answer 3

एक तीसरा विकल्प है, जहां आप टेबल बनाते हैं और यदि आवश्यक हो तो कॉलम जोड़ते हैं। यह इस बात पर निर्भर करता है कि कितने रूप बनाए गए हैं, लेकिन डेटाबेस आसानी से कई तालिकाओं को संभाल सकते हैं। इसलिए यदि कोई उपयोगकर्ता 'कार पंजीकरण फॉर्म' फ़ॉर्म जोड़ना चाहता है, तो आप एक तालिका 'CarRegistrationForm' जोड़ते हैं। प्रत्येक फ़ील्ड के लिए वे फॉर्म पर चाहते हैं, आप उन्हें कुछ बुनियादी प्रकारों के बीच दिनांक, int और टेक्स्ट के रूप में चुन सकते हैं। और जब टेक्स्ट चुना जाता है, तो उन्हें एक पिक सूची से अधिकतम लंबाई दर्ज करनी होती है, जो फ़ील्ड को वर्चर या क्लोब होना चाहिए, जो आपको जानकारी देता है।

यह SQL सर्वर पर काम करता है, जहां आप आसानी से कॉलम जोड़ और छोड़ सकते हैं। डीबी 2 के लिए यह एक समस्या हो सकती है, क्योंकि ड्रॉप कॉलम लागू नहीं किया गया है। MySQL के लिए मुझे यकीन नहीं है।

आपको अभी भी दो अलग-अलग तालिकाओं में अपने फॉर्म और फ़ील्ड पंजीकृत करने की आवश्यकता है।

Answer 4

आप शायद चाहते Entity-Relationship Model

वास्तव में जीयूआई उपकरण जैसे मॉडल से सहभागी स्कीमा बनाने के लिए कर रहे हैं।