क्या यह संभव के रूप में कुछ तालिकाओं के साथ एक डेटाबेस बनाने के लिए आवश्यक है

Question

क्या हमें कम से कम तालिकाओं के साथ एक डेटाबेस संरचना तैयार करनी चाहिए?

क्या इसे इस तरह से डिज़ाइन किया जाना चाहिए कि सब कुछ एक ही स्थान पर रहे या अधिक तालिकाओं का होना ठीक है?

यह वैसे भी कुछ भी प्रभावित करेगा?

मैं यह सवाल पूछ रहा हूं क्योंकि मेरे एक दोस्त ने मीडियाविकी में कुछ डेटाबेस संरचना को संशोधित किया है। अंत में, 20 तालिकाओं के बजाय वह केवल 8 का उपयोग कर रहा था, और उसे ऐसा करने में 8 महीने लग गए (यह उसका कॉलेज असाइनमेंट था)।

संपादित करें

मैं इस जवाब को समाप्त कर रहा हूं: जब तक कि मामला असाधारण न हो, तब तक तालिकाओं का आकार मायने नहीं रखता; जिस स्थिति में अपभ्रंश मदद कर सकता है।

जवाब के लिए सभी को धन्यवाद।

Comments

तालिकाओं की न्यूनतम संख्या आसान है, बस संपूर्ण को मास्टर_टेबलाइज करें (table_name, col_name, col_type, row_id, value)।

— इंका

क्या? मुझे नहीं मिल रहा है

— Shaheer

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

— इंका

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

— शहीर

@ Hamza: यह बेहतर प्रदर्शन प्रदान कर सकता है । यह वास्तव में विशिष्ट परिस्थितियों पर निर्भर करता है। ठोस जवाब देने के लिए हमारे यहाँ लगभग पर्याप्त जानकारी नहीं है ।

— FrustratedWithFormsDesigner

Answer 1

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

यदि आपके दोस्त को केवल 8 तालिकाओं की आवश्यकता है, और सिस्टम उसके साथ ठीक काम करता है, तो 8 सही संख्या है, और शेष 12 जो कुछ भी वह कर रहा था उसके लिए आवश्यक नहीं था।

संभावित अपवाद अजीब वातावरण हो सकते हैं जिनकी तालिका संख्याओं पर कठोर सीमाएं हैं, लेकिन मैं अपने सिर के ऊपर से इस तरह के सिस्टम का एक ठोस उदाहरण नहीं सोच सकता हूं।

Comments

+1:If your major concern is quantity of tables, you should probably not be designing database systems.

— जोएल एथरटन

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

— आरोन

+1, हालांकि मुझे नहीं लगता कि हम यह कहना पर्याप्त जानते हैं कि उनके मामले में सही संख्या 8 है, क्योंकि हम स्कीमा की तुलना नहीं कर सकते हैं (मूल वर्तमान के लिए आवेदन की तुलना में उच्चतर लेन-देन की मात्रा के लिए बेहतर हो सकता है) उदाहरण)

— एडम रॉबिन्सन

@ Hamza: ठीक है, इसलिए उसके पास अच्छे PHP कौशल और अच्छे डेटाबेस कौशल हो सकते हैं, और उस परियोजना को दोनों की आवश्यकता हो सकती है - लेकिन यह धारणा न बनाएं कि एक होने का मतलब दूसरे से है। कई डेवलपर्स के पास एक कौशल हो सकता है लेकिन दूसरा नहीं।

— FrustratedWithFormsDesigner

@ टॉम एंडरसन - तब भी आपको डेटाबेस सिस्टम डिज़ाइन नहीं करना चाहिए।

— जोएल एथरटन

Answer 2

एक डेटाबेस में उतनी ही मेजें होनी चाहिए जितनी की जरूरत है। न कम, न ज्यादा।

Comments

english.stackexchange.com/questions/495/less-vs-fewer इसे चर्चा में बदलने के लिए नहीं, लेकिन यहां "कम" बनाम "कम" बहस पर एक दिलचस्प चर्चा की जा रही है, जिसमें इसकी उत्पत्ति भी शामिल है, इंग्लिश एसई से , क्योंकि यह आप लोगों को उत्साहित करने के लिए लगता है;)

— कोरी

Answer 3

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

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

Comments

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

— maple_shaft

@मैप पूरी तरह से सहमत हैं। आपको यह निर्धारित करने के लिए प्रोफाइल करना होगा कि डेटा के कौन से सेट को समूहीकृत करना है, इसलिए IMO को आपको सामान्यीकृत करने की आवश्यकता है। YMMV, विशेषज्ञ शायद इसे अपने सिर के ऊपर से कर सकते हैं :) जेफ के पास एक ऐसा पद है, जिसके बारे में आपको पता चलता है कि आपको दिलचस्प लग सकता है।

— माइकल के

अच्छा और संक्षिप्त पोस्ट, मैंने इसे पहले पढ़ा है! कभी-कभी आप दोनों दुनिया का सबसे अच्छा लाभ उठा सकते हैं। यदि रिपोर्टिंग को 100% वास्तविक समय की आवश्यकता नहीं है, तो दो स्कीमा बनाए रखें, एक मुख्य स्कीमा अनुप्रयोग उपयोग के लिए लेनदेन सामान्यीकृत स्कीमा, और दूसरा एक सामान्य स्कीमा जो नियमित रूप से स्ट्रीम किया जाता है और रिपोर्टिंग डेटा एक्सेस के लिए सिलवाया जाता है।

— maple_shaft

: स्टार स्कीमा का स्पष्टीकरण भी विषय पर अधिक जानकारी publib.boulder.ibm.com/infocenter/rbhelp/v6r3/...

— maple_shaft

@maple_shaft, मैं इस बात से सहमत हूं कि प्रदर्शन डेटाबेस को अक्सर प्रदर्शन के लिए घोषित किया जाता है, लेकिन वे ऐसा कुछ नहीं हैं जो मैं उम्मीद करता हूं कि एक छात्र या जूनियर प्रोग्रामर को लेने की अनुमति दी जाएगी। मुझे पता है कि मैं निश्चित रूप से अपने डेटा वेयरहाउस को किसी ऐसे व्यक्ति द्वारा नियंत्रित करने की अनुमति नहीं दूंगा जिनके पास विशेषज्ञता नहीं है।

— HLGEM

Answer 4

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

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

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

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

Comments

Google ने बिगटेबल डिज़ाइन किया और जानबूझकर इसमें शामिल नहीं किया गया क्योंकि यह समानांतर नहीं है।

— रेयान

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

— HLGEM

+1 आपके लिए, @HLGEM, उत्तर और टिप्पणी दोनों के लिए; यह कई डेवलपर्स को देखने के लिए शर्म की बात है कि दस्तावेज़ डेटाबेस बैंडवागन पर कूदते हैं क्योंकि उन्हें लगता है कि "जॉइन = स्लो", केवल जाने के लिए और रिलेशनल डेटाबेस को हल करने की कोशिश करने के लिए जो 20 साल पहले रिलेशनल डेटाबेस द्वारा हल किए गए थे।

— एडम रॉबिन्सन

Answer 5

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

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

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

Comments

धन्यवाद, यह एक बहुत स्पष्ट है !, और मैं है सामान्यीकरण के बारे में btw पढ़ा है, मैं इसे यह भी cakePHP डेटाबेस है, जो एक और और कुछ हद तक अलग दृष्टिकोण को प्रोत्साहित करती है में करते हैं।

— शाहीन

Answer 6

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

Answer 7

तालिकाओं की न्यूनतम संख्या होने से मुझे एक बहुत अजीब लक्ष्य के रूप में जाना जाता है।

निश्चित रूप से एक स्कीमा को 20 टेबल से घटाकर 8 तक ले जाना एक अच्छी बात हो सकती है (यदि अच्छा किया जाए तो इससे जुड़ाव कम हो सकता है और प्रदर्शन में वृद्धि हो सकती है, अप्रयुक्त स्तंभों को हटा दिया जा सकता है) लेकिन यह समान रूप से समझने और आगे बढ़ने के लिए कठिन बना सकता है।

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

बेशक यह धीमी गति से प्रदर्शन भी कर सकता है (यह मानकर कि डेटाबेस को अच्छी तरह से डिज़ाइन किया गया था)।

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

Answer 8

नंबर महत्वपूर्ण नहीं है। डिजाइन है। कुछ प्रणालियों को देखें। Magento, PHPBB, आदि उनके सिस्टम में दर्जनों टेबल हैं और ठीक काम करते हैं।

Answer 9

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

Answer 10

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

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

Answer 11

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

मैं विवरण में नहीं जा रहा हूँ, लेकिन मुझे लगता है कि बहुत ही वास्तविक तथ्य यह है कि तालिकाओं की संख्या प्रदर्शन को प्रभावित कर सकती है, यही एक कारण है कि NoSQL डेटाबेस जैसे कि कैसंड्रा, मानगो और Google बिगटेबल (सिक!) का आविष्कार किया गया है, और यही कारण है कि वे डेटा के सामान्यीकरण को प्रोत्साहित करते हैं (और फलस्वरूप बड़ी संख्या में तालिकाओं / संग्रह आदि से बचते हैं)।

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

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

Answer 12

अंकल बॉब का तर्क था कि मोर सिंपल है।

Http://c2.com/cgi/wiki?FearOfAddingTables देखें

"एक अच्छा डिज़ाइन आम तौर पर तालिकाओं को जोड़कर सरल किया जाता है"

मेरा मानना ​​है कि लगभग सभी इकाइयां कई-कई हैं, जिनमें अधिक तालिकाओं की आवश्यकता होती है।

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

Answer 13

तो जवाब है हां।

लेकिन निर्भर करें कि तालिकाओं की "न्यूनतम" संख्या का सही अर्थ क्या है।

उदाहरण के लिए (एक विरोधी उदाहरण)।

अगर मेरे पास अगली वस्तुएं हैं

1. उपयोगकर्ताओं
2. ग्राहकों

और दोनों एक ही राज्य (क्षेत्र) साझा करते हैं और तब सुरक्षा प्रतिबंध नहीं होते हैं, यह एक ही तालिका करने के लिए अधिक अनुकूल है

1. table_persons

बल्कि दो अलग-अलग टेबल

1. table_users
2. table_customers

मेज की तुलना में विपक्ष हमारे लिए एक नया क्षेत्र (type_of_person) जोड़ने की आवश्यकता होगी।

अन्य गलती (गलती अगर यह वास्तव में करने की आवश्यकता नहीं है) एक तालिका को "विभाजित" करना है, इस रूप में पढ़ें: दो में एक एकल तालिका को अलग करें।

1. table_persons

दो तालिकाओं में

1. table_info_persons
2. table_extra_info_persons

क्योंकि आप दो तालिकाओं में शामिल होने के लिए कुछ प्रश्नों के लिए मजबूर कर रहे हैं और यह खराब है।

Comments

अरे आपका जवाब बहुत ही वर्णनात्मक है और मदद कर रहा है, धन्यवाद

— शहीर

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

-1: उपयोगकर्ताओं और ग्राहकों के अलग-अलग क्षेत्र हैं; यदि इस समय नहीं है, तो वे भविष्य में किसी बिंदु पर होंगे। इसलिए वे अलग-अलग टेबल के लायक हैं।

— सोजेरड

@Sjoerd, @Chris: जबकि अक्सर ऐसा हो सकता है, यह जरूरी नहीं कि सच हो। उस तरह की चीजें अनुप्रयोग-निर्भर हैं। कहा जा रहा है, मैं भावना से सहमत हूं। बहुत बार डेटाबेस डेवलपर्स "सामान्य क्षेत्र के नाम" देखेंगे इसका मतलब है कि यह समान डेटा है। यह विशेष रूप से करना आसान हो जाता है जब आप पहले ओआरएम से डेटाबेस को देखते हैं (दूसरे शब्दों में, पीछे की तरफ)। जबकि OO अवधारणाओं को डेटाबेस में मॉडल किया जा सकता है, डेटाबेस पंक्तियों और संबंध हैं, न कि वस्तुएं ।

— एडम रॉबिन्सन

+1 के लिए "डेटाबेस पंक्तियाँ और संबंध हैं, वस्तुएं नहीं", मैं इसे अपने fav उद्धरणों में जोड़ दूंगा!

— शहीर