MySQL में बहुत सारे फ़ील्ड?

Question

मैंने कुछ साल पहले एक सीखने की परियोजना के रूप में एक गेम के लिए एक आंकड़े साइट विकसित की थी। आज भी इसका उपयोग किया जाता है और मैं इसे थोड़ा साफ करना चाहता हूं।

डेटाबेस एक ऐसा क्षेत्र है जहां सुधार की आवश्यकता है। मेरे पास गेम आंकड़े के लिए एक टेबल है, जिसमें गेमआईडी, प्लेयरआईडी, किल्स, डेथ्स, डैमेजडिल्ट, डैमेजटेकन इत्यादि हैं। कुल मिलाकर, उस तालिका में लगभग 50 फ़ील्ड हैं और भविष्य में कई और जोड़े जा सकते हैं। किस बिंदु पर बहुत सारे क्षेत्र हैं? वर्तमान में इसमें 57,341 पंक्तियां हैं और 153.6 एमआईबी स्वयं ही हैं।

मेरे पास कुछ फ़ील्ड भी हैं जो इस तालिका में बीएलओबी में सरणी संग्रहीत करते हैं। सरणी का एक उदाहरण प्लेयर बनाम प्लेयर मैचअप है। सरणी स्टोर करती है कि उस खिलाड़ी ने गेम में कितनी बार मार डाला था। ये फाइलसाइज में बड़े क्षेत्र हैं। एक बीएलओबी सलाह में एक सरणी भंडारित कर रहा है?

 [Killed] => Array 
      (
       [SomeDude] => 13 
       [GameGuy] => 10 
       [AnotherPlayer] => 8 
       [YetAnother] => 7 
       [BestPlayer] => 3 
       [APlayer] => 9 
       [WorstPlayer] => 2 
      ) 

ये 10 से अधिक खिलाड़ियों से अधिक नहीं करते हैं:

सरणी की तरह दिखता है।

Answer 1

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

हां, तो आप

user: 
id | username | some_other_required_field 

user_data: 
id | user_id | label | value 

अब आप के रूप में अधिक या कम user_data पंक्तियों के रूप में आप प्रति उपयोगकर्ता की जरूरत हो सकता है होगा।

[संपादित करें]

अपने सरणी के रूप में, मैं इस एक संबंधपरक तालिका के साथ साथ ही व्यवहार करेगी। कुछ ऐसा:

player_interraction: 
id | player_id | player_id | interraction_type 

यहां आप दो खिलाड़ियों को स्टोर करेंगे जिनके साथ बातचीत हुई थी और यह किस तरह की बातचीत थी।

Answer 2

टेबल डिज़ाइन अधिकतर ठीक लगता है। जब तक आप जिन स्तंभों को संग्रहीत कर रहे हैं, उन्हें उसी पंक्ति के अन्य कॉलम से गणना नहीं की जा सकती है। आईई, आप सेल्फकिल्स, अन्यडिथ, और टोटलडिथ्स को संग्रहित नहीं कर रहे हैं (जहां टोटलडिथ्स = सेल्फकिल्स + अन्यडिथ)। यह समझ में नहीं आता है और आपकी मेज से काटा जा सकता है।

मैं बीओएलबी में उन Arrays को संग्रहीत करने के बारे में और जानना चाहता हूं - बीएलओबी में वे किस उद्देश्य से सेवा करते हैं? आसान डेटा परिवर्तन और विश्लेषण के लिए वे तालिका में सामान्य क्यों नहीं हैं? (या वे हैं और वे उपयोगकर्ताओं को समाप्त करने के लिए डेटा प्रदर्शन में आसान के लिए यहां एक सरणी के रूप में संग्रहीत किए जा रहे हैं)।

इसके अलावा, मैं उत्सुक हूं कि आपके बीएलओबी की शेष तालिका बनाम कितनी डेटा लेती है। आम तौर पर, पंक्तियों का आकार पंक्तियों की संख्या के रूप में एक सौदे के रूप में बड़ा नहीं है, और ~ 60 के बिल्कुल कोई बड़ा सौदा नहीं है। जब तक आप उन प्रश्नों को नहीं लिख रहे हैं जिन्हें प्रत्येक कॉलम मान की जांच करने की आवश्यकता है (आदर्श रूप से आप कहां लिखने की कोशिश करते समय ब्लॉब्स को अनदेखा कर रहे हैं)।

Answer 3

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

सामान्य रूप से अपने डीबी के आकार के बारे में चिंता न करें, लेकिन संरचना के बारे में सोचें और यह कैसे व्यवस्थित और अनुक्रमित है। मैंने बकवास की तरह छोटे डीबी की दौड़ देखी है।

यदि आप अभी भी संख्या चाहते हैं, तो जब आप कुल डीबी जीबी रेंज में हों या एक टेबल में कुछ सौ हजार पंक्तियां पाएं, तो चीजों के बारे में अधिक चिंता करना शुरू करें - 60K पंक्तियों में 150 मीटर अधिक नहीं है और टेबल स्कैन आपको प्रदर्शन में ज्यादा खर्च नहीं कर रहे हैं। हालांकि, अब यह सुनिश्चित करने का समय है कि आप अपने भारी इस्तेमाल किए गए प्रश्नों पर अच्छी कवरिंग इंडेक्स बनाएं।

Answer 4

समय सारिणी के साथ डेटाबेस तालिका में कॉलम जोड़ने में कुछ भी गलत नहीं है। डेटाबेस डिजाइन हर समय बदल जाते हैं। ध्यान में रखना यह है कि डेटा को कैसे समूहीकृत किया जाता है। मैंने हमेशा वस्तुओं की सूची के रूप में डेटाबेस तालिका का इलाज किया है।

बातें मैं विचार इस प्रकार हैं:

जब एक पंक्ति में डेटा डालने कितने कॉलम अशक्त हो जाएगा?
क्या यह नया कॉलम मेरे डेटा का 80% पर लागू होता है जो पहले से मौजूद है?
क्या मैं इस तालिका में कुछ कॉलम के लिए कई अपडेट करूँगा?
यदि हां, तो क्या मुझे ट्रैक रखने की आवश्यकता है कि प्रीवियोस मूल्य क्या हैं?

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