मुझे पता है कि आप एक ही समय में कई चीजों से जूझ रहे हैं, लेकिन सबसे अच्छा जवाब उस समस्या को हल करता है जो ikegami जल्दी से पारित हो गया पर्ल में इसे करने के अपने रास्ते पर:
लोग अक्सर एप्लिकेशन स्तर पर आवश्यकता से अधिक करते हैं क्योंकि वे डेटाबेस में सही चीजें करना कभी नहीं सीखते हैं (जैसे कि आपका अन्य प्रश्न जिसे पर्ल के बजाय उपयुक्त SQL क्वेरी द्वारा बेहतर उत्तर दिया गया है)। लेकिन, एक तरफ के रूप में, बहुत से लोग ऐसा इसलिए करते हैं क्योंकि वे स्कीमा को बदलने में असमर्थ हैं। सामाजिक अनुमान, जैसे कि बीयर का उपयुक्त अनुप्रयोग, कभी-कभी उस पथ को सुगम बनाता है। डेटाबेस के लोगों को समझाने का एक छोटा सा काम बाद में गुणकों में भुगतान करता है। और, दूसरी तरफ, "पूर्ण स्टैक डेवलपर" अक्सर डेटाबेस के किसी भी परिष्कृत उपयोग को छोड़ देता है।
मैं किसी को भी सी.जे. तिथि का डेटाबेस इन डेप्थ पढ़ने के लिए प्रेरित नहीं करने जा रहा हूं। , लेकिन स्कीमा को सही करने में बहुत अधिक मूल्य है। ठीक से, मेरा मतलब है कि यह अपने उपयोग पर कम से कम प्रयास और जटिलता लगाता है। चीजें आसान होनी चाहिए, और आपको इन चीजों को एप्लिकेशन स्तर पर पुनर्व्यवस्थित नहीं करना चाहिए।
आप गिनना चाहते हैं कि प्रत्येक उत्तर कितनी बार चुना गया है। काउंटिंग कुछ ऐसा है जो डेटाबेस बहुत अच्छा करते हैं, इसलिए डेटाबेस को इसे करने दें।
आपके कुछ प्रश्न हैं। सवालों के अलग-अलग जवाब हैं। सर्वेक्षण समूह एक साथ प्रश्नों के समूह। लोग अपने उत्तरों को प्रश्नों के साथ जोड़कर सर्वेक्षण का जवाब देते हैं।
यहाँ एक साधारण स्कीमा डिज़ाइन है (और कुछ डेटाबेस आदमी अंततः दिखाई देंगे और मुझे बताएंगे कि मैंने इसे सही नहीं किया, लेकिन यह ठीक है)। चाल यह है कि अप्रयुक्त होने वाले कई कॉलम नहीं हैं। सब कुछ एक साफ छोटे पैकेज ("रिलेशनल डेटाबेस" में "रिलेशन") में आता है जो आसानी से "विदेशी कुंजी" के माध्यम से अन्य चीजों से जुड़ा होता है (उदाहरण के लिए प्रश्न का उत्तर मैप करने के लिए प्रश्न_आईडी)। उत्तर, उदाहरण के लिए, एक ही question_id . के लिए अनेक पंक्तियां होंगी ।
अगर कोई फैंसी मॉडलिंग टूल के साथ आना चाहता है और चित्र बनाना चाहता है, तो इसके लिए जाएं। मैं इसे समुदाय विकि के रूप में चिह्नित कर रहा हूं।
Table: Questions
id
text
Table: Answers
id
text
question_id
Table: Surveys
id
title
Table: SurveyQuestionSet
id
survey_id
question_id
Table: Respondent
id
text
Table: Response
id
respondent_id
survey_id
question_id
answer_id
एक बार मैप आउट और सामान्य रूप से ठीक से (सामान्य रूपों पर पढ़ें ), SELECTs के साथ आप जो डेटा चाहते हैं उसे प्राप्त करना बहुत आसान है। सामान्यीकरण का आदर्श केवल जानकारी को दोहराना नहीं है या इसे असंगत स्थिति में आने देना है। इन रूपों में, बहुत सी चीज़ें करना बहुत आसान हो जाता है।
और, यदि आप ऐसी चीजों का अभ्यास करना चाहते हैं, तो Stackoverflow Data Explorer मैंने जो यहां प्रस्तुत किया है, उसके लिए सामान्यीकृत एक वास्तविक जीवन डेटा सेट है।
अब आप केवल answer_id . की संख्या गिनें सर्वेक्षण और प्रश्न के एक विशेष संयोजन के लिए दिखाई देता है। GROUP BY . का चालाकी से उपयोग आपके लिए सभी काम करता है। अब आपको उन दसियों अप्रयुक्त स्तंभों को देखते हुए पंक्तियों के माध्यम से पुनरावृति करने की आवश्यकता नहीं है जो यह पता लगाने की कोशिश कर रहे हैं कि उन्हें कैसे गिनना है। इतना ही नहीं, आप इन चीजों को views
बना सकते हैं। , जिसका अर्थ है कि आप एक बार क्वेरी लिखते हैं और डेटाबेस दिखाता है कि इसके परिणाम एक तालिका हैं। फिर आप केवल दृश्य को क्वेरी कर सकते हैं (इसलिए सभी JOIN s और इसी तरह छिपे हुए हैं), जो बहुत आसान है। संग्रहित प्रक्रियाओं को भी अक्सर अनदेखा कर दिया जाता है।
