एक सर्वेक्षण के लिए डेटाबेस डिजाइन [बंद]


129

मुझे एक सर्वेक्षण बनाने की आवश्यकता है जहां उत्तर एक डेटाबेस में संग्रहीत किए जाते हैं। मैं सोच रहा हूं कि डेटाबेस में इसे लागू करने का सबसे अच्छा तरीका क्या होगा, विशेष रूप से आवश्यक तालिकाओं का। सर्वेक्षण में विभिन्न प्रकार के प्रश्न शामिल हैं। उदाहरण के लिए: टिप्पणियों के लिए पाठ फ़ील्ड, बहुविकल्पीय प्रश्न और संभवतः ऐसे प्रश्न जिनमें एक से अधिक उत्तर हो सकते हैं (यानी लागू होने वाले सभी की जांच करें)।

मैं दो संभावित समाधानों के साथ आया हूँ:

  1. एक विशाल तालिका बनाएं जिसमें प्रत्येक सर्वेक्षण प्रस्तुत करने के लिए उत्तर हों। प्रत्येक कॉलम सर्वेक्षण से एक उत्तर के अनुरूप होगा। यानी सर्वेआईडी, उत्तर 1, उत्तर 2, उत्तर 3

    मुझे नहीं लगता कि यह सबसे अच्छा तरीका है क्योंकि इस सर्वेक्षण में बहुत सारे सवाल हैं और यदि सर्वेक्षण को बदलना है तो यह बहुत लचीला नहीं है।

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

    एक सरल उदाहरण:

    tblSurvey : सर्वेआईडी

    tblQuestion : QuestionID, SurveyID , QuestionType, Question

    tblAnswer : AnswerID, UserID , QuestionID , उत्तर

    tblUser : यूजरआईडी , यूजरनेम

    इसके साथ मेरी समस्या यह है कि उत्तर के टन हो सकते हैं जो उत्तर तालिका को बहुत बड़ा बना देगा। मुझे यकीन नहीं है कि जब यह प्रदर्शन की बात आती है तो यह बहुत अच्छा है।

मैं किसी भी विचार और सुझाव की सराहना करेंगे।


"बहुत बड़ा" कितना है? हमें एक अनुमान दें, क्या हम एक मिलियन या एक हजार मिलियन के बारे में बात कर रहे हैं?
जॉर्ज कोर्डोबा

1
SQL सर्वर वास्तव में 'टन' डेटा के साथ काम करने के लिए डिज़ाइन किए गए हैं। आपको उस योजना के साथ काम करने में बहुत परेशानी नहीं होनी चाहिए जिसके बारे में आपने बात की है।
क्रिस

जवाबों:


122

मुझे लगता है कि आपका मॉडल # 2 ठीक है, हालांकि आप अधिक जटिल मॉडल पर एक नज़र डाल सकते हैं जो प्रश्नों और पूर्व-निर्मित उत्तरों (प्रस्तावित उत्तरों) को संग्रहीत करता है और उन्हें अलग-अलग सर्वेक्षणों में फिर से उपयोग करने की अनुमति देता है।

- एक सर्वेक्षण में कई प्रश्न हो सकते हैं; एक प्रश्न कई सर्वेक्षणों में इस्तेमाल किया जा सकता है।
- कई सवालों के लिए एक (पूर्व-निर्मित) उत्तर की पेशकश की जा सकती है। एक प्रश्न में कई उत्तर दिए जा सकते हैं। एक प्रश्न के अलग-अलग सर्वेक्षणों में प्रस्तुत अलग-अलग उत्तर हो सकते हैं। विभिन्न सर्वेक्षणों में विभिन्न प्रश्नों के उत्तर दिए जा सकते हैं। एक डिफ़ॉल्ट "अन्य" उत्तर है, यदि कोई व्यक्ति दूसरे को चुनता है, तो उसका उत्तर Answer.OtherText में दर्ज किया जाता है।
- एक व्यक्ति कई सर्वेक्षणों में भाग ले सकता है, एक व्यक्ति केवल एक बार सर्वेक्षण में विशिष्ट प्रश्न का उत्तर दे सकता है।

survey_model_02


1
डेटाबेस स्कीमा बनाने के लिए आपने किस टूल का उपयोग किया?
अंधेरबाग

मैं Altova UModel का उपयोग करता हूं। यह त्वरित है, मॉडलिंग संरचनाओं की एक विस्तृत चयन प्रदान करता है, और हर प्रारूप को बहुत अधिक बचाता है। हालांकि, यह खर्च होता है।
obimod

9
आप draw.io का भी उपयोग कर सकते हैं। यह मुफ़्त w / नो साइनअप और उपयोग करने में आसान है।
usr4896260

3
हमारे पास Survey_Question_Answerऔर क्यों है Answer? अभी Answerपर्याप्त नहीं है?
अबुबकर अहमद

1
मुझे लगता Answerहै कि पर्याप्त है, Survery_question_answerबेमानी है
बैटमैन

62

मेरा डिज़ाइन नीचे दिखाया गया है

नवीनतम बनाएं स्क्रिप्ट https://gist.github.com/durrantm/1e618164fd4acf9191372 पर है

स्क्रिप्ट और mysql वर्कबेंच.mwb फ़ाइल https://github.com/durrantm/survey पर भी उपलब्ध हैं
यहाँ छवि विवरण दर्ज करें


नमस्ते, मुझे आपका डिज़ाइन पसंद है। कृपया तालिकाओं के लिए कोई डेटा सैंपल (डंप) लें? वास्तव में सराहना करेंगे
Emeka Mbah

हाय! पहले अपने काम के लिए धन्यवाद यह बहुत बढ़िया है! क्या आपने अपने किसी टेम्पलेट में पदानुक्रम पर विचार किया होगा? उपयोगकर्ता आमतौर पर अपने नेता के बारे में जानकारी देते हैं और इन नेताओं को अपने नेताओं और इसी तरह के बारे में जानकारी होती है। और उपयोगकर्ता विभिन्न अनुभागों (एचआर, प्रोडक्शन) में काम करते हैं और इनका एक पदानुक्रम भी हो सकता है। इसलिए रिपोर्टिंग के दौरान इन संगठन स्तरों के बीच अंतर करना अक्सर आवश्यक होता है।
रुएदी जूल

@michael: यह वास्तव में उपयोगी है। क्या आपके पास वसंत का उपयोग करके जावा के लिए कोई संदर्भ / लिथुब लिंक है?
सागर पंडा

मैं अभी भी पता लगाने के लिए क्या बीच का अंतर है कोशिश कर रहा हूँ option_groupsऔर option_choicesऔर क्या उपयोग है।
9

@PHPnoob मुझे लगता है कि जैसा कि नाम से पता चलता है, बस समूह विकल्प हैं। इसलिए यदि आप उदाहरण के लिए 1 से 5 के बीच की दर लगा सकते हैं, तो आपको option_groupsयह अनुमति देनी चाहिए कि अगर मुझे यह अधिकार मिल रहा है।
डिस्प्लेनामे

18

निश्चित रूप से # 2 विकल्प, मुझे भी लगता है कि आपके पास वर्तमान स्कीमा में एक निरीक्षण हो सकता है, आप एक और तालिका चाहते हैं:

+-----------+
| tblSurvey |
|-----------|
| SurveyId  |
+-----------+

+--------------+
| tblQuestion  |
|--------------|
| QuestionID   |
| SurveyID     |
| QuestionType |
| Question     |
+--------------+

+--------------+
| tblAnswer    |
|--------------|
| AnswerID     |
| QuestionID   |
| Answer       |
+--------------+

+------------------+
| tblUsersAnswer   |
|------------------|
| UserAnswerID     |
| AnswerID         |
| UserID           |
| Response         |
+------------------+

+-----------+
| tblUser   |
|-----------|
| UserID    |
| UserName  |
+-----------+

प्रत्येक प्रश्न में उत्तर की एक निश्चित संख्या होती है, जिसे उपयोगकर्ता चुन सकता है, फिर वास्तविक प्रतिक्रियाओं को दूसरी तालिका में ट्रैक किया जाएगा।

डेटाबेस बहुत सारे डेटा स्टोर करने के लिए डिज़ाइन किए गए हैं, और अधिकांश पैमाने बहुत अच्छी तरह से। वहाँ अब जगह पर बचाने के लिए बस कम सामान्य रूप उपयोगकर्ता के लिए कोई वास्तविक जरूरत नहीं है।


नमस्ते, मेरा एक प्रश्न है। सर्वेआईड उत्तर तालिका में मौजूद नहीं होना चाहिए या कम से कम सर्वेक्षण के संस्करण के समय का मिलान करते हुए एक स्टैम्प होना चाहिए? यदि आपने अपने मूल सर्वेक्षण में एक प्रश्न डाला है, तो प्रश्न बदल जाएगा, और उत्तर अज्ञात हो जाएंगे। या अगर यह बेमानी है, तो आप कैसे समझा सकते हैं?
शुभम

3

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

मुझे लगता है कि आपका दूसरा दृष्टिकोण सबसे अच्छा है, लेकिन अगर आप निश्चित हैं कि आपको बहुत से पैमाने की चिंताएं हैं, तो एक बात जो मेरे लिए अतीत में काम की है, वह है हाइब्रिड दृष्टिकोण:

  1. प्रति-प्रश्न प्रतिक्रियाओं को संग्रहीत करने के लिए विस्तृत प्रतिक्रिया तालिकाएँ बनाएं जैसा कि आपने 2 में वर्णित किया है। यह डेटा आमतौर पर आपके एप्लिकेशन से सीधे क्वेरी नहीं किया जाएगा, लेकिन इसका उपयोग रिपोर्टिंग टेबल के लिए सारांश डेटा बनाने के लिए किया जाएगा। आप शायद इस डेटा के लिए किसी प्रकार के संग्रह या विस्तार को लागू करना चाहते हैं।
  2. यदि आवश्यक हो तो 1 से प्रतिक्रिया तालिका भी बनाएं। जब भी उपयोगकर्ता परिणामों के लिए एक साधारण तालिका देखना चाहते हैं तो इसका उपयोग किया जा सकता है।
  3. रिपोर्टिंग उद्देश्यों के लिए किए जाने वाले किसी भी विश्लेषण के लिए, 1 से डेटा के आधार पर अतिरिक्त सारांश डेटा बनाने के लिए नौकरियों को शेड्यूल करें।

यह पूरी तरह से लागू करने के लिए एक बहुत अधिक काम है, इसलिए मैं वास्तव में यह सलाह नहीं दूंगा जब तक कि आप निश्चित रूप से नहीं जानते कि यह तालिका बड़े पैमाने पर चिंताओं में चलने वाली है।


1

दूसरा तरीका सबसे अच्छा है।

यदि आप इसे सामान्य करना चाहते हैं तो आप प्रश्न प्रकारों के लिए एक तालिका बना सकते हैं

करने के लिए सरल चीजें हैं:

  • डेटाबेस रखें और अपनी डिस्क पर लॉग ऑन करें, सी पर सभी डिफ़ॉल्ट के रूप में नहीं
  • डेटाबेस को आवश्यकतानुसार बड़ा बनाएं ताकि डेटाबेस के बढ़ने के दौरान आपके पास ठहराव न हो

हमारे पास 10 लाख पंक्तियों के साथ SQL सर्वर तालिका में लॉग टेबल है।


1

कोई 2 ठीक नहीं लगता।

केवल 4 कॉलम वाली तालिका के लिए यह एक समस्या नहीं होनी चाहिए, यहां तक ​​कि कुछ लाख पंक्तियों के साथ भी। बेशक यह इस बात पर निर्भर कर सकता है कि आप किस डेटाबेस का उपयोग कर रहे हैं। यदि इसका कुछ SQL सर्वर जैसा है तो यह कोई समस्या नहीं होगी।

आप शायद प्रश्नावली फ़ील्ड पर tblAnswer टेबल पर एक इंडेक्स बनाना चाहते हैं।

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


0

एक smiple सर्वेक्षण के लिए बहुत अच्छा लग रहा है। 'खुले मूल्यों' के लिए एक तालिका जोड़ना न भूलें, जहां एक ग्राहक एक टेक्स्टबॉक्स के माध्यम से अपनी राय प्रदान कर सकता है। अपने जवाब के लिए एक विदेशी कुंजी के साथ उस तालिका को लिंक करें और प्रदर्शन के लिए अपने सभी संबंधपरक कॉलमों पर अनुक्रमित करें।


1
क्या कोई कारण है कि मैं उत्तर तालिका के भीतर टिप्पणियाँ भी नहीं डाल सका?
माइकल

0

नंबर 2 सही है। जब तक आप किसी प्रदर्शन समस्या का पता नहीं लगाते हैं, तब तक सही डिज़ाइन का उपयोग करें। अधिकांश RDBMS को संकीर्ण लेकिन बहुत लंबी तालिका के साथ कोई समस्या नहीं होगी।


0

एक बड़ी उत्तर तालिका, अपने आप में, कोई समस्या नहीं है। जब तक सूचकांक और बाधाओं को अच्छी तरह से परिभाषित किया जाता है तब तक आपको ठीक होना चाहिए। आपका दूसरा स्कीमा मुझे अच्छा लग रहा है।


0

उचित सूचकांक को देखते हुए आपका दूसरा समाधान एक पारंपरिक संबंधपरक डेटाबेस सिस्टम के लिए सामान्यीकृत और अच्छा है।

मुझे नहीं पता कि यह कितना बड़ा है, लेकिन इसे समस्या के बिना एक-दो मिलियन जवाब देना चाहिए।


0

आप पूरे फॉर्म को JSON स्ट्रिंग के रूप में संग्रहीत करना चुन सकते हैं।

अपनी आवश्यकता के बारे में निश्चित नहीं है, लेकिन यह दृष्टिकोण कुछ परिस्थितियों में काम करेगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.