Mysql
 sql >> डेटाबेस >  >> RDS >> Mysql

इष्टतम दृष्टिकोण की तलाश में, डीबीएमएस में डायनामिक फॉर्म डेटा संग्रहीत करना

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

  • आपके पास एक document है (या प्रश्नावली ) जिसमें अनेक questions हों . ये दोनों काफी सामान्य हैं और इन्हें अपनी टेबल की आवश्यकता होती है, जैसा आपने अभी तक किया है।
  • प्रत्येक प्रश्न का एक type होता है जो परिभाषित करता है कि यह किस प्रकार का प्रश्न है (एकाधिक चयन, मुक्त रूप, एक का चयन करें... ) और निश्चित रूप से प्रश्न में options . भी हैं . तो यह दो टेबल अधिक है। यहां तर्क यह है कि इन्हें वास्तविक प्रश्न से अलग करने से कुछ स्तर के अमूर्त अस्तित्व की अनुमति मिलती है और आपके प्रश्न अभी भी कुछ हद तक सरल होंगे, हालांकि संभवतः loooooong।

तो, प्रत्येक दस्तावेज़ में प्रश्नों के लिए 1..n है, प्रत्येक प्रश्न में 1 प्रकार और 1..n विकल्प हैं। थोड़ा सा छोड़कर, मैं लिंक टेबल इत्यादि के बारे में सोच रहा हूं।

Document
    bigint id
DocumentQuestions
    bigint document_id
    bigint question_id
Question
    bigint id
    varchar question
QuestionType
    bigint question_id
    bigint type_id
Type [pre-filled table with id:type pairs, such as 1=freeform, 2=select one etc.]
QuestionOptions
    bigint id
    bigint question_id
    varchar description
    varchar value

Answers
    bigint id
    bigint document_id
    [etc. such as user_id]
QuestionAnswers
    bigint answer_id
    bigint question_id
    bigint questionoptions_id

इस प्रकार का डिज़ाइन कई चीज़ों की अनुमति देता है:

  • प्रश्न स्वयं पुन:प्रयोज्य हैं, यदि आप एक सामान्य "y प्रश्नों के पूल से इन x यादृच्छिक प्रश्नों का उत्तर दे रहे हैं, तो बहुत आसान है ".
  • मौजूदा प्रकार को तोड़े बिना नए प्रकार आसानी से जोड़े जा सकते हैं।
  • आप हमेशा संरचना के माध्यम से काफी आसानी से नेविगेट कर सकते हैं, उदाहरण के लिए "मेरे पास इस एकल प्रश्न उत्तर के लिए दस्तावेज़ का नाम क्या था? " या "कितने लोगों ने इस एक प्रश्न का गलत उत्तर दिया है?"
  • चूंकि प्रकार अलग-अलग होते हैं, आप एक (वेब) UI बना सकते हैं जो डेटाबेस में स्थिति को आसानी से दर्शाता है - बेहतर अभी तक, यदि प्रकार बदलता है तो आपको अपने UI कोड को बिल्कुल भी स्पर्श नहीं करना पड़ सकता है।
  • चूंकि प्रश्न के लिए प्रत्येक संभावित विकल्प QuestionOptions में अपनी स्वयं की पंक्ति है तालिका, आप वास्तविक मूल्य बहुत आसानी से प्राप्त कर सकते हैं।

इसके साथ स्पष्ट समस्या यह है कि इसे अखंडता के लिए तालिकाओं के बीच काफी सख्त युग्मन की आवश्यकता होती है और शुरुआत में ठीक से चलने में दर्द होगा। साथ ही value . के बाद से QuestionOptions . में वर्चर है, आपको सामान को बहुत अधिक पार्स करने में सक्षम होना चाहिए और आप रूपांतरण संकेतों के लिए एक और फ़ील्ड भी पेश करना चाहेंगे।

आशा है कि यह मदद करता है, भले ही आप मेरे समाधान से बिल्कुल सहमत नहीं होंगे।




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. उपयोगकर्ता के स्थान के आधार पर क्वेरी डेटाबेस मान

  2. पीएचपी पीडीओ बाइंडपरम () और माईएसक्यूएल बिट

  3. ASP.NET में mysql पैरामीटरयुक्त क्वेरी

  4. MySQL में एक तिथि से वर्ष और महीना कैसे प्राप्त करें

  5. एसएसएल पर PHP MySQL। पीयर सर्टिफिकेट मैच नहीं हुआ