हजारों पंक्तियों के साथ वेबसाइट के हर उपयोगकर्ता (हजारों) के लिए एक एसक्यूएल टेबल बनाएं?

Question

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

अब, हमारे पास हजारों प्रश्न और हजारों उपयोगकर्ता होंगे। चूंकि प्रत्येक प्रश्न में कम से कम 4 उत्तर होंगे और हम भी दिए गए गलत उत्तरों को ट्रैक करना चाहते हैं, मेरा सवाल यह है कि: इस विशेष मामले में, क्या प्रति उपयोगकर्ता एक टेबल रखना समझ में आता है?

मुझे पता है कि तालिका-प्रति-उपयोगकर्ता प्रश्न पहले से ही पूछा गया है (here, उदाहरण के लिए), लेकिन मुझे लगता है कि यह वास्तव में एक अलग मामला है।

तो: हजारों पंक्तियों के साथ लाखों पंक्तियों या हजारों तालिकाओं वाली एक तालिका?

Answer 1

यह प्रति उपयोगकर्ता डेटाबेस ऑब्जेक्ट रखने का कभी भी समझ में नहीं आता है। यदि आप अपनी तालिका और डेटाबेस संरचना को उचित रूप से डिज़ाइन करते हैं, तो दस लाख पंक्तियों वाली एक तालिका आसानी से प्रबंधित होती है।

एक टेबल-प्रति-उपयोगकर्ता बहुत अप्रबंधनीय होगा, और यह नहीं है कि रिलेशनल डेटाबेस आमतौर पर डिज़ाइन किए जाते हैं।

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

Answer 2

कई आरडीएमएस आपको विभाजित टेबल बनाने देते हैं; मुझे लगता है कि आपके मामले में सबसे अच्छा विकल्प होगा (सभी उपयोगकर्ताओं के लिए एक विभाजित तालिका; आप जिस आरडीएमएस का उपयोग कर रहे हैं, उस पर निर्भर करता है, आपके पास विभाजन कुंजी निर्दिष्ट करने के लिए अलग-अलग विकल्प होंगे)

Answer 3

सामान्य उत्तर यह है कि "प्रति उपयोगकर्ता तालिका" एक भयानक डिज़ाइन है, और सरल समाधान स्वामित्व की पहचान करने के लिए एक अतिरिक्त फ़ील्ड के साथ एक एकल तालिका है।

उदा।

table_1 table_2 table_3 ...... table_999999999 
id  id   id    id 
...  ...  ...   ... 

रहा है

table 
id 
user 
... 

होने जबकि संसाधनों के एक बड़े पैमाने पर बेकार, अब तक का प्रतिनिधित्व करने के लिए आसान है।

Answer 4

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

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

उपयोगकर्ता तालिका: शामिल अपने सभी उपयोगकर्ताओं सवाल: सभी प्रश्न शामिल हैं

परिणाम: सभी परिणाम UserID, test_id, समय शामिल

टेस्ट testID, questionid, उत्तर, time_to_complete

उत्तर answer_id, उत्तर

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

प्रस्तुत का जवाब तो डेटा कैसा दिखेगा है:

Results 
UserID, TestID, Time 
1   1  00:11 

Test 
TestID QuestionID, answers, time_to_complete 
1  1    1   00:10:00 
1  2    2   00:01:00 

Answers 
answer_id, Answers 
    1   A 
    1   B 
    2   A 
    3   A 
    3   B 
    3   C 

यह दृष्टिकोण आप प्रत्येक उपयोगकर्ता के लिए विशिष्ट डेटा का चयन करें, देखते हैं कितनी बार वे एक परीक्षण आदि ले लिया है जाने हैं और हजारों टेबलों से प्रबंधित करना बहुत आसान होगा।