mysql बहुत सारे कॉलम?

Question

मैं 30-50 कॉलम के साथ एक टेबल बना रहा हूं। इन पंक्तियों में से लगभग 200K हैं। क्या यह डेटा अलग टेबल में स्टोर करने की अनुशंसा की जाती है? क्या आपके पास कई कॉलम होने पर प्रदर्शन समस्याएं हैं।

मैं तालिका के बारे में थोड़ा सा समझाऊंगा। मुझे पिछले 10 सालों में बास्केटबाल, बेसबॉल, फुटबॉल, हॉकी) में सभी स्पोर्ट्स गेम्स स्टोर करना होगा। इनमें से प्रत्येक के लिए, मुझे अतिरिक्त डेटा रखने की आवश्यकता है। इस डेटा में से कुछ मुझे खेल भर में खेतों का पुन: उपयोग करने की अनुमति देता है। उदाहरण के लिए, प्रत्येक टीम में एक घर और दूर टीम और एक घटना की तारीख होती है।

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

यदि आवश्यक हो तो मैं अधिक विशिष्टता दे सकता हूं। किसी भी सामान्य सलाह के लिए अग्रिम धन्यवाद।

Answer 1

RichardOD के जवाब पर विस्तार से बता दें आप आमतौर पर उप-टाइपिंग से निपटने के दौरान तीन विकल्प होते हैं, और जो आप चुनते हैं उस पर निर्भर करता है कि आपको डेटा के साथ क्या करना है।

पहला विकल्प वह है जिसे आप वर्तमान में उपयोग कर रहे हैं: एक तालिका में विभिन्न प्रकार से संबंधित सभी कॉलम रखें, झंडे और नल के साथ यह इंगित करने के लिए उपयोग किया जाता है कि किस प्रकार का रिकॉर्ड दिया गया है। यह सबटाइपिंग का प्रबंधन करने का सबसे आसान तरीका है, और यह आमतौर पर अच्छी तरह से काम करता है जब आपके पास केवल कुछ प्रकार होते हैं या यदि विभिन्न प्रकार बहुत अलग नहीं होते हैं। आपके मामले में, ऐसा लगता है कि प्रकार काफी भिन्न हो सकते हैं।

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

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

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

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

Answer 2

मुझे लगता है कि समस्या यह है कि आपके पास model like this है (स्टोर एक टेबल दृष्टिकोण में सबकुछ)। This approach और this approach आपके द्वारा चुने गए विकल्पों में से दो हैं- मुझे यकीन है कि दूसरों के पास कुछ और सुझाव होंगे।

उनके सभी के पास उनके पेशेवर और विपक्ष हैं। मैं MySQL में प्रदर्शन विशेषताओं पर टिप्पणी नहीं कर सकता, लेकिन निश्चित रूप से अन्य दृष्टिकोण नल के उपयोग को कम करते हैं, जो केवल एक अच्छी बात हो सकती है।

यदि आप 3 दृष्टिकोणों के बीच मतभेदों में वास्तव में रूचि रखते हैं, तो मैं मार्टिन फाउलर के एंटरप्राइज़ एप्लिकेशन आर्किटेक्चर पुस्तक के पैटर्न खरीदने की सलाह दूंगा।

प्रदर्शन विशेषताओं के संदर्भ में - आप like this one और also this one पर प्रश्न देखना चाहेंगे।

आप vertical partitioning in MySql here पढ़ सकते हैं।

Answer 3

मैं निश्चित रूप से normalizing the table पर देखता हूं। हालांकि, मुझे प्रदर्शन लाभों के बारे में निश्चित नहीं है, लेकिन बड़ी संख्या में प्रविष्टियों के साथ भंडारण लाभ होने की संभावना अधिक होगी।

मेरा पहला परिवर्तन किसी भी डेटा को केवल 1 या 2 खेल से संबंधित है है और मुख्य तालिका से एक विदेशी कुंजी के साथ अलग तालिकाओं में उन्हें करने के लिए किया जाएगा

Answer 4

हां, अगर यह समझ में आता है तो बहुत सारे कॉलम का उपयोग करें। बशर्ते आप "field1, field2, field3" आदि जैसे एंटीपेटर्न का उपयोग नहीं कर रहे हैं, तो यह ठीक है।

बहुत सारे एनयूएलएल अच्छे हैं, वे ज्यादा चोट नहीं पहुंचाते हैं। 200k भी ऐसी पंक्तियों की एक छोटी संख्या है जो आपको कई प्रदर्शन समस्याओं को देखने की संभावना नहीं है। मुझे नहीं पता कि आप इस तालिका में कितने आवेषण करने की योजना बना रहे हैं, लेकिन यदि यह < प्रति सेकंड 100 है, तो मुझे कोई समस्या नहीं दिख रही है।

आप इसे किसी भी तरह से अनुक्रमित करना चाहते हैं। इंडेक्स की संख्या सम्मिलित प्रदर्शन को प्रभावित करेगी, लेकिन मुझे लगता है कि आपके अधिकांश कॉलम को अनुक्रमित करने की आवश्यकता नहीं होगी।

ऐसी छोटी तालिका के साथ यह वास्तव में बहुत अधिक मायने रखता नहीं है - इसमें से कोई भी नहीं। आप किसी भी स्थान की समस्याओं के बिना अपने डेटा को कई बार डुप्लिकेट कर सकते हैं- आप एक विशेषाधिकार प्राप्त स्थिति में हैं।

Answer 5

200K बार 50 मान एक बड़ी मेज नहीं है। प्रदर्शन के बारे में चिंता न करें जब तक आपके पास उपयोग की आसानी और नियंत्रण में आत्म विरोधाभास से स्वतंत्रता जैसी चीजें न हों।

तालिका को विघटित करने के कई कारण हैं। एक तालिका को विघटित करना मतलब है कि इसे दो या दो से अधिक तालिकाओं में विभाजित करना, अधिकांश कॉलम केवल एक तालिका में जा रहे हैं, और अन्य कॉलम एक से अधिक तालिका (विदेशी कुंजी) में जा रहे हैं।

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

यदि मुझे 40 कॉलम या उससे अधिक के साथ डेटाबेस तालिका में पेश किया गया था और डेटाबेस (प्रदर्शन, भ्रष्टाचार, या जो कुछ भी) में किसी भी तरह की समस्या थी, तो मैं देखता हूं कि उस तालिका को और सामान्यीकृत किया जा सकता है, और ऐसा करने की लागत/लाभ क्या हैं।

तालिका को विभाजित करने के कई कारण हैं। जैसा कि रेनरपोस्ट ने कहा, तब तक पार्टियों के बारे में चिंता करना शुरू न करें जब तक आपको नियंत्रण में सामान्यीकरण नहीं मिल जाता।