प्रश्नावली डेटाबेस डिजाइन - कौन सा तरीका बेहतर है?

15

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

एक ग्राहक केवल एक प्रश्न सेट कर सकता है: प्रति 100 प्रश्न एक ग्राहक।
पुराने दृष्टिकोण के लिए मैं डेटाबेस में सवाल नहीं रखता लेकिन इसके बजाय PHP कोडिंग में निरंतरता प्रदान करता हूं। समस्या यह है कि मुझे पीएचपी में प्रश्न की तुलना करने के लिए इसे डेटाबेस में उत्तर के साथ सिंक्रनाइज़ करना होगा। यदि एक प्रश्न को PHP से बदल / हटा / हटा दिया गया था, तो मैं निश्चित रूप से प्रश्नावली डेटाबेस में उत्तर के साथ इसे मैच करने के लिए खो दूंगा। बेहतर समाधान?
क्या मैं एक उत्तर के रूप में कई तत्वों से प्राप्त कई उत्तरों को एक क्षेत्र में रखने में सक्षम हो सकता हूं? मैं इस फ़ील्ड को कैसे पुनः प्राप्त कर सकता हूं और इसे फिर से ग्राहक के रूप में देखने के लिए प्रदर्शित कर सकता हूं?
मुझे नीचे किस विकल्प के लिए जाना चाहिए?

विकल्प 1: पुराना दृष्टिकोण (1 टेबल)

टेबल: प्रश्नावली

आईडी (PK)
ग्राहक आईडी, ग्राहक पहचान
स्थिति
ए 1
ए 2
ए 3
।
।
।
A100

विकल्प 2: नया दृष्टिकोण (2 टेबल)

तालिका: प्रश्न

QID (PK)
प्रश्न (varchar)

तालिका: उत्तर

एआईडी (पीके)
ग्राहक आईडी, ग्राहक पहचान
QID (int)
उत्तर (varchar)

या विकल्प 3?

database-design

— मॉड्यूलर
स्रोत

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

— ज़ाम्बोनिली

हां और नहीं क्रमशः (डायनेमिक प्रश्न बाद में दूसरे चरण में हो सकता है लेकिन अब नहीं।)

— मॉड्यूलर

मैंने इस 100 प्रश्नों को बंद करने के लिए मतदान किया है : इनपुट, बहुविकल्पी, चेकबॉक्स, रेडियो बटन, टेक्सारिया, और फ़ाइल अपलोड से भिन्न होना उपयोगी होने के लिए बहुत व्यापक है।

— इवान कैरोल

17

निश्चित रूप से अपने प्रश्नावली को हार्ड कोड न करें। एक रिलेशनल डेटाबेस या xml फ़ाइलों का उपयोग करें। मैं निम्नलिखित तालिकाओं का प्रस्ताव करता हूं

Questionnaire: प्रश्नावली का सामान्य विवरण। शीर्षक, सर्वेक्षण का नाम, प्रश्नावली रिलीज की तारीख, संस्करण, और इसी तरह।
Section: अनुभाग एक प्रश्नावली से बना है। अनुभाग की संख्या, अनुभाग शीर्षक, विवरण।
Question: एक खंड से संबंधित प्रश्न। प्रश्न की संख्या, प्रश्न पाठ, विवरण, प्रश्न प्रकार (पाठ, बहुविकल्पी, आदि)।
Question_Choice: एकल चेकबॉक्स, रेडियो बटन, और इसी तरह एक प्रश्न से संबंधित संभावित उत्तर। पसंद, पसंद संख्या, आदेश का पाठ।
Respondent: सवालों के जवाब देने वाले व्यक्ति। व्यक्तिगत डेटा, उपयोगकर्ता संख्या।
Interview: एक प्रतिवादी और एक प्रश्नावली से संबंधित साक्षात्कार या परीक्षण या सर्वेक्षण (प्रश्नावली की प्रकृति पर निर्भर)। यदि कोई प्रतिवादी हमेशा केवल एक प्रश्नावली का उत्तर दे सकता है (या यदि सर्वेक्षण अनाम है), तो यह तालिका अप्रचलित है और इसे प्रतिसाद तालिका के साथ मिलाया जा सकता है। साक्षात्कार तिथि (या परीक्षण तिथि या सर्वेक्षण तिथि), साक्षात्कारकर्ता (यदि यह लागू होता है)।
Answer: एक साक्षात्कार (या प्रतिवादी, ऊपर देखें) और एक प्रश्न से संबंधित उत्तर। उत्तर पाठ (पाठ प्रकार के प्रश्नों के लिए), पसंद (रेडियो बटन के लिए)।
Answer_Choice: एक विकल्प और एक प्रश्न_ विकल्प से संबंधित विकल्प जब कई विकल्पों की जाँच की जा सकती है।

यह एक बहुत ही सामान्यीकृत दृष्टिकोण है; हालाँकि, आप विकल्पों को एक स्ट्रिंग में बदलने या उन्हें बिट पैटर्न के रूप में संग्रहीत करने या अपनी आवश्यकताओं के आधार पर किसी अन्य तरीके से सरल बनाने का निर्णय ले सकते हैं।

— ओलिवियर जैकोट-डेसकोम्बेस
स्रोत

6

आपको कुछ तालिकाओं की आवश्यकता है,

1 - प्रश्न (प्रश्न आईडी, इनपुट प्रकार, दृश्यमान, प्रश्न प्रकार, प्रश्न पाठ, अपेक्षित उत्तर ....)

2 - उत्तर (प्रश्न आईडी, उपयोगकर्ता आईडी, गतिविधि आईडी, उत्तर ....)

3 - उपयोगकर्ता (उपयोगकर्ता आईडी, उपयोगकर्ता नाम ......)

4 - एक प्रश्न / उत्तर गतिविधि (गतिविधि आईडी, डेटा / समय, उपयोगकर्ता आईडी) रखने के लिए एक तालिका

आप एक तालिका भी पसंद कर सकते हैं जो उन प्रश्नों को निर्दिष्ट करती है जिन्हें प्रत्येक गतिविधि के लिए लागू किया जाना चाहिए - या तो उपयोगकर्ता या शायद एक प्रश्न संग्रह द्वारा समूहीकृत। विदेशी / प्राथमिक कुंजी वे कॉलम होंगे जिनका एकाधिक तालिकाओं में समान नाम है और उन्हें अनुक्रमित किया जाना चाहिए।

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

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

(एक टिप, अपनी प्रस्तुति परत बनाने के लिए, आपको एक क्वेरी की आवश्यकता होगी जिसे प्रदर्शित करने के लिए उपयुक्त प्रश्न मिलते हैं, फिर इस परिणाम के माध्यम से लूप करें और स्क्रीन पर प्रश्न करने के लिए रेंडर करने के लिए एक विधि को कॉल करें, चुने जाने के तरीके उपयुक्त हैं उस प्रश्न की प्रस्तुति [पाठ बॉक्स, रेडियो समूह, आदि])

— अदाम च
स्रोत

+1 टेबल # 4 के बारे में निश्चित नहीं है, लेकिन कुल मिलाकर अच्छा जवाब है। विशेष रूप से मुझे एकवचन तालिका नामों से बहुवचन अर्थात प्रश्न >> प्रश्न में परिवर्तन पसंद है।

— लेह रिफ़ेल