MySQL: कई कॉलम के साथ एकाधिक टेबल या एक टेबल?

Question

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

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

मैं डेटाबेस डिज़ाइन के लिए काफी नया हूं, इसलिए कौन सा दृष्टिकोण बेहतर है और पेशेवर और विपक्ष क्या हैं? ऐसा करने का पारंपरिक तरीका क्या है?

Answer 1

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

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

आप database normalization दिलचस्प पर विकिपीडिया लेख मिल सकती है, क्योंकि यह गहराई में इस के लिए कारणों की चर्चा:

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

Denormalization भी कुछ के बारे में पता हो सकता है, क्योंकि ऐसे मामले हैं जहां डाटा दोहरा बेहतर है (क्योंकि यह काम की राशि डेटाबेस जब डाटा पढ़ने के लिए जरुरी है कम कर देता है) है। मैं अत्यधिक शुरू करने के लिए अपने डेटा को सामान्यीकृत करने की सलाह देता हूं, और यदि आप विशिष्ट प्रश्नों में प्रदर्शन समस्याओं से अवगत हैं तो केवल तब्दील हो जाएं।

Answer 2

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

Answer 3

यदि आप सब कुछ एक टेबल में रखते हैं, तो अपने आप से ये प्रश्न पूछें, क्या आपके पास उस उपयोगकर्ता के लिए कई पंक्तियां होंगी? यदि आपको किसी उपयोगकर्ता को अपडेट करना है तो क्या आप ऑडिट ट्रेल रखना चाहते हैं? क्या उपयोगकर्ता डेटा तत्व के एक से अधिक उदाहरण हो सकता है? (उदाहरण के लिए फोन नंबर की तरह) क्या आपके पास ऐसा कोई मामला होगा जहां आप बाद में तत्व या तत्वों को सेट करना चाहते हैं? यदि आप हाँ का जवाब देते हैं तो संभवतः आप विदेशी कुंजी संबंधों के साथ बाल तालिकाओं को रखना चाहते हैं।

माता-पिता/बाल सारणी के पेशेवर डेटा अखंडता, इंडेक्स के माध्यम से प्रदर्शन (हाँ आप इसे एक फ्लैट टेबल पर भी कर सकते हैं) और आईएमओ को बनाए रखने के लिए आसान है यदि आपको बाद में कोई फ़ील्ड जोड़ने की ज़रूरत है, खासकर यदि यह आवश्यक हो खेत।

विपक्ष डिजाइन कठिन है, प्रश्नों थोड़ा और अधिक जटिल

बन लेकिन, कई मामलों ताकि आप तय करने के लिए अपनी स्थिति को देखने के लिए है, जहां एक बड़ा फ्लैट तालिका उचित होगा देखते हैं।

Answer 4

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

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

Answer 5

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

Answer 6

मेरे पास है एक अच्छा उदाहरण। रिश्तों के निम्नलिखित सेट के साथ बहुत ज्यादा सामान्यीकृत डेटाबेस:

people -> rel_p2staff -> staff 

और

people -> rel_p2prosp -> prospects 

कहाँ लोगों के नाम और व्यक्तियों विवरण होता है कि कर्मचारी सिर्फ कर्मचारी रिकॉर्ड विवरण होता है कि संभावनाओं सिर्फ संभावनाओं का विवरण, और rel है टेबल कर्मचारियों और संभावनाओं से जुड़े लोगों से विदेशी कुंजी के साथ संबंध तालिकाओं हैं।

इस प्रकार का डिज़ाइन पूरे डेटाबेस के लिए चलता है।

अब संबंधों के इस सेट को पूछने के लिए यह हर बार एक बहु-तालिका में शामिल होता है, कभी-कभी 8 और अधिक तालिका में शामिल होते हैं। यह इस साल के मध्य तक ठीक काम कर रहा है, जब अब यह बहुत धीमी हो रही है कि हम लोगों के 40000 रिकॉर्ड पिछले हैं।

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

समाधान people -> staff के लिए एक सीधा संबंध और people -> prospect

Answer 7

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