एक संबंधपरक डेटाबेस में ईमानदारी की कमी - क्या हमें उनकी अनदेखी करनी चाहिए?


10

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

विचाराधीन मंच MySQL 5.x है, और कोई FOREIGN कुंजी स्थापित नहीं की गई है, यहां तक ​​कि संबंधित तालिकाओं के कुछ प्राथमिक कुंजी अवरोध गायब हैं, जो कम से कम मेरे लिए, उचित नहीं है। शायद वे सही हैं और मैं गलत हूं, लेकिन मेरे पास इस स्थिति के बारे में चर्चा करने के लिए पर्याप्त तर्क नहीं हैं।

यह तीन वर्षों के लिए पसंदीदा तरीका रहा है। मैं इस कंपनी में नया हूँ (केवल एक महीना) लेकिन, जैसा कि उत्पाद "काम करता है", डेटाबेस को बढ़ाने में हिचकिचाहट है; nevertheles, पहली बात जिस पर मैंने गौर किया, वह है एक पेज लोड होने में 1 मिनट (हाँ, 60 सेकंड!)।

वर्तमान मामलों के पीछे एक दावा यह है कि एक "डीमनर्लाइज़्ड" डेटाबेस एक सामान्यीकृत की तुलना में तेज़ है, लेकिन मुझे विश्वास नहीं है कि यह सच है।

अधिकांश प्रासंगिक प्रश्नों में JOIN ऑपरेशंस शामिल हैं, जो उन्हें बड़ी मात्रा में डेटा के साथ बहुत, बहुत धीमी गति से चलाते हैं (डेटाबेस में लाखों पंक्तियाँ होती हैं)।

आमतौर पर, एप्लिकेशन प्रोग्राम कोड स्तर पर "CRUD" संचालन का संचालन कार्यान्वित किया जाता है; उदाहरण के लिए, कुछ आंकड़ों से हटाने के लिए, आइए बताते हैं TableA:

  • अगर और की पंक्तियों के बीच कुछ संबंध है, तो पहले मक्खी पर जांच करना आवश्यक है , TableAऔरTableB
  • यदि ऐसा कहा जाता है कि संबंध "पता लगाया गया" है, तो ऐप प्रोग्राम कोड को उचित पंक्ति (पंक्ति) को नष्ट करने की अनुमति नहीं देगा, लेकिन
  • यदि किसी कारण से ऐप प्रोग्राम कोड विफल हो जाता है, तो DELETE ऑपरेशन "सफल" होगा, इससे कोई फर्क नहीं पड़ता कि इसमें शामिल पंक्तियों और तालिकाओं के संबंध में कोई संबंध है या नहीं।

सवाल

क्या आप मुझे बहस को समृद्ध करने के लिए एक अच्छा, सटीक और ठोस जवाब देने में मदद कर सकते हैं?


नोट : हो सकता है कि ऐसा कुछ पहले पूछा (और उत्तर दिया गया हो), लेकिन मुझे Google के माध्यम से कुछ भी नहीं मिला।


टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।
पॉल व्हाइट 9

जवाबों:


12

यदि, जैसा कि आपकी पोस्ट में कहा गया है, इरादा एक संबंधपरक डेटाबेस (संक्षिप्तता के लिए आरडीबी) बनाने का है, इसलिए, यह उम्मीद की जाती है कि यह इस तरह से कार्य करता है, संक्षिप्त उत्तर है:

  • नहीं, आपको डेटा अखंडता बाधाओं की अनदेखी नहीं करनी चाहिए

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

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

इस संबंध में, मैं (a) मेरी समग्र बाधाओं को साझा करूंगा और (b) डेटाबेस के मामलों की स्थिति और कार्य वातावरण के बारे में कई विचार इस प्रकार है।

प्रमुख कुंजी बाधाओं, डेटा संबंधों और संदर्भात्मक अखंडता

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

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

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

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

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

इसी तरह, डेटा - एक महत्वपूर्ण संगठनात्मक संसाधन- स्वाभाविक रूप से अनुप्रयोग कार्यक्रमों, अनुप्रयोग प्रोग्रामर, अनुप्रयोग विकास प्लेटफार्मों और प्रोग्रामिंग प्रतिमानों को रेखांकित करता है।

प्राथमिक कुंजी बाधाओं और नकली पंक्तियों के निहितार्थ

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

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

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

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

इस तरह:

  • कौन सा "संस्करण" सही, विश्वसनीय माना जा सकता है?
  • कौन सा वास्तविक दुनिया को सही ढंग से दर्शाता है?

जैसा कि आप जानते हैं, इस घटना के कानूनी निहितार्थ भी हो सकते हैं, एक ऐसी परिस्थिति जो निश्चित रूप से बहुत महत्वपूर्ण है।

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

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

पीके की एक और लाभप्रद संपत्ति यह है कि, जब एकल या मिश्रित FK में भाग लेने के लिए अन्य तालिकाओं में "माइग्रेट" किया जाता है, तो वे डेटा के बीच मौजूद रिश्तों के कार्डिनैलिटी अनुपात को लागू करने में मदद कर सकते हैं । यह सब, हाँ, डीबीएमएस द्वारा सुनिश्चित की गई सरल और कुशल घोषणात्मक सेटिंग्स के माध्यम से।

(वर्तमान) CHECK बाधाओं और एकल पंक्ति सत्यापन

हमें (वर्तमान) CHECK बाधाओं की प्रासंगिकता के बारे में नहीं भूलना चाहिए, जो कि पंक्ति के स्तंभ मानों के वैध सेट को प्रतिबंधित करता है (जो सरल दिखाई दे सकता है, लेकिन वास्तव में एक संबंधपरक DBMS की एक मूलभूत विशेषता है), इसे बनाने के लिए अच्छी तरह से मदद करें निश्चित है कि व्यावसायिक संदर्भ के नियम हर समय सटीक रूप से परिलक्षित होते हैं।

जैसा कि आपने MySQL टैग के साथ अपने प्रश्न को चिह्नित किया है, यह उल्लेख किया जाना चाहिए कि, दुर्भाग्य से, इस तरह के एक मंच ने इस तरह की बाधा की घोषणा की अनुमति दी है, लेकिन एक ही समय में, इसके प्रवर्तन को अनदेखा करता है! , स्थिति, जो कि, 2004 से बग के रूप में बताई गई थी

इस संबंध में, आपको अन्य तरीकों से इस कारक का ध्यान रखना होगा, उदाहरण के लिए, ACID ट्रांजेक्शंस, ट्राइगर, या DBMS के भीतर अन्य तरीके ( इस विषय पर जानकारी के लिए @ ypercubeᵀᴹ द्वारा यह उत्तर देखें ) ताकि डेटा जारी रहे निरतंरता बनाए रखें।

सहायता बाधाओं: आगे बहु-पंक्ति और बहु-तालिका व्यापार नियमों को घोषित रूप से स्थापित करना

एक पहलू यह है कि जिन कारणों से बहुत खराब तरीके से समर्थित हैं- अलग-अलग SQL DBMSs द्वारा, जिसमें MySQL भी शामिल है, बहु-पंक्ति और मल्टी-टेबल बाधाओं को एक घोषणापत्र में सक्षम कर रहा है —बाइक पीके और एफके, स्पष्ट रूप से।

इसके भाग के लिए, SQL मानक में कई वर्षों से ASSERTIONs शामिल हैं। मुझे नहीं पता कि आपके व्यवसाय के वातावरण के नियम उस तार्किक-स्तर के सत्यापन के दृष्टिकोण से क्या लाभान्वित होंगे, लेकिन एक डेटाबेस डिजाइनर के रूप में, मैं मानता हूं कि एक या अधिक ASSERTIONs के साथ डेटा को कम करना बहुत आसान होगा, हालांकि मुझे इसका उल्लेख करना होगा DBMS डेवलपर्स के दृष्टिकोण से, इस सर्वोपरि प्रकार के उपकरण को अमूर्तता के भौतिक स्तर पर लागू करना मुश्किल है।

ऐसा प्रतीत होता है कि ओरेकल विक्रेता और / या डेवलपर्स 2016 से ASSERTION समर्थन का मूल्यांकन कर रहे हैं , और यह उस DBMS को और अधिक प्रासंगिक रूप से अनुपालन करेगा और इसलिए, अधिक मजबूत और प्रतिस्पर्धी। मुझे लगता है कि, अगर (i) उनके उपभोक्ता धक्का देते रहते हैं और (ii) ओरेकल कार्यान्वयन में सफल होता है, तो (iii) अन्य DBMS विक्रेताओं / समुदायों को उन्हें भी सक्षम करना होगा, और उनका उपयोग फैलाना शुरू हो जाएगा। निश्चित रूप से, डेटाबेस प्रबंधन क्षेत्र में यह बहुत बड़ी प्रगति होगी, और डॉ। कोडड द्वारा परिकल्पित सबसे विशिष्ट उपकरणों में से एक होने के नाते, मुझे व्यक्तिगत रूप से उम्मीद है कि हम जल्द ही ऐसा होते हुए देखेंगे।

डेटा संगतता और निर्णय लेने की प्रक्रिया

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

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

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

"असमान्यीकरण"

काश, "एक 'सामान्यीकृत' डेटाबेस एक सामान्यीकृत की तुलना में तेज़ है" एक व्यापक रूप से फैली हुई भ्रांति है, हालांकि यह एक तर्क भी है जिसे तार्किक, भौतिक और व्यावहारिक आधार पर नकारा जा सकता है।

सबसे पहले, निरूपण का तात्पर्य यह है कि आधार तालिका को पहले सामान्यीकृत किया गया है (एक औपचारिक , विज्ञान-आधारित, एक डेटाबेस के अमूर्त स्तर पर तार्किक स्तर पर पूरी की गई प्रक्रिया के आधार पर)।

तो, यह सोचते हैं कि कहा तालिका वास्तविक तथ्य सही ढंग से सामान्य में था, "denormalizing" यह (जो, शब्द की औपचारिक अर्थ के विपरीत, एक में यह कॉलम कि में हैं, और यह भी का हिस्सा हैं, अन्य तालिकाओं को जोड़कर शामिल विज्ञापन होक फैशन), सहायता कर सकता है, उदाहरण के लिए, (भौतिक स्तर पर) केवल एक या कुछ विशेष सेलेक्ट स्टेटमेंट के प्रसंस्करण में तेजी लाने के लिए, जबकि इस तरह की कार्रवाई एक ही समय में, कई अन्य संबंधित डेटा के निष्पादन को कम कर सकती है। हेरफेर संचालन (उदाहरण के लिए, कई INSERT, UPDATE, DELETE और SELECT स्टेटमेंट्स, या उनमें से संयोजन एक या एक से अधिक ACID लेनदेन के भीतर संलग्न हैं)।

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

भौतिक-स्तर वाले मचान सामान्यीकृत और "अपभ्रंश" तालिकाओं का समर्थन करते हैं

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

इस तरीके से, एक "डिनरलाइज्ड" टेबल आवश्यक रूप से "व्यापक" (अतिरिक्त कॉलम रखने) होगा जिसका अर्थ है कि इसकी पंक्तियाँ आवश्यक रूप से भारी (अधिक और बड़े भौतिक-स्तर के घटकों की आवश्यकता होगी), इसका मतलब है कि अंतर्निहित कंप्यूटिंग प्रक्रियाएं (जैसे , जो हार्ड ड्राइव या मेमोरी के साथ करना है) आसानी से धीमी गति से बदल सकते हैं।

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

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

विचाराधीन डेटाबेस का कामकाज

आपके प्रश्न के निम्नलिखित पैराग्राफ को डेटा पुनर्प्राप्ति कार्यों की गति के साथ करना है:

[ए] उत्पाद "काम करता है", डेटाबेस को बढ़ाने में संकोच होता है; फिर भी, पहली बात जो मैंने देखी, वह है एक पेज लोड होने में 1 मिनट (हाँ, 60 सेकंड!)।

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

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

अधिकांश प्रासंगिक प्रश्नों में JOIN ऑपरेशंस शामिल हैं, जो उन्हें बड़ी मात्रा में डेटा के साथ बहुत, बहुत धीमी गति से चलाते हैं (डेटाबेस में लाखों पंक्तियाँ होती हैं)।

यह ध्यान देने योग्य है कि JOIN ऑपरेटर एक आवश्यक और शक्तिशाली तत्व है जो डेटा के संबंधपरक हेरफेर से संबंधित है। फिर, हालांकि अधिक मजबूत प्लेटफ़ॉर्म तुलनात्मक रूप से तेज़ निष्पादन के साथ इसकी सेवा करते हैं, जिस परिस्थिति का आप वर्णन करते हैं वह संभवतः एक गैर-सामान्य डिज़ाइन का एक लक्षण है (अमूर्त की वैचारिक, तार्किक और भौतिक स्तरों पर)। तो, मेरी पहली नजर के अनुमान हैं:

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

इसके अलावा, हाँ, जैसा कि @TommCatt ने अपने उत्तर में उल्लेख किया है , कभी-कभी एक क्वेरी का (तार्किक) पुनर्लेखन एक बार फिर से इसकी (भौतिक) निष्पादन योजना को डेटा रीडिंग / राइटिंग को तेज करता है, जो एक कारक है जिसे निश्चित रूप से ध्यान में रखा जाना चाहिए।


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

9

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

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

के तहत नहीं है, किसी भी परिस्थिति में, एक OLTP डेटाबेस से निकालें FKS।

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

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

आप डेवलपर्स द्वारा लिखित से अधिक जटिल प्रश्नों को रखना चाह सकते हैं। उनसे पूछें कि उन्हें कौन सा डेटा चाहिए और वे किस प्रारूप में चाहते हैं। फिर उन्हें इसे देने के लिए विचार प्रदान करें। जटिल प्रश्नों के विचार होंगे। तब डेवलपर्स को केवल लिखना होता है:

select <something> from <SomeView> where <whatever>;

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

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


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

2

शीर्षक बदलने से सवाल बदल जाता है। FOREIGN KEYsवैकल्पिक हैं। वे करते हैं:

  • एक एफके स्पष्ट रूप INDEXसे तालिकाओं में से एक में बनाता है । इस तरह के सूचकांक को मैन्युअल रूप से जोड़ा जा सकता है। (इसलिए इसके लिए एफके की आवश्यकता नहीं है ।)
  • एक एफके अखंडता के लिए जाँच करता है। यह प्रसिद्धि के लिए एफके का मुख्य दावा है। एफके की आवश्यकता नहीं है क्योंकि आपका आवेदन समान जांच कर सकता है, या यह तय कर सकता है कि चेक की आवश्यकता नहीं है। इसलिए...
  • अखंडता चेक प्रदर्शन में कुछ खर्च करता है; इसलिए यह प्रसंस्करण धीमा कर देती है। (यह आमतौर पर कोई बड़ी बात नहीं है।)
  • एफके हर वो चीज नहीं करते जो हर कोई चाहता है; इस मंच के साथ "क्यों FKs एक्स नहीं कर सकते हैं" सवाल है। विशेष रूप से CHECKविकल्प पर कार्रवाई नहीं की जाती है।
  • एफके CASCADEचीजें कर सकते हैं। (व्यक्तिगत रूप से, मैं नियंत्रण में रहना पसंद करता हूं, और यह नहीं मानता कि एफके 'सही काम करेगा'।)

एफके के लिए निचला रेखा: कुछ लोग एफके पर जोर देते हैं; कुछ उत्पाद उनके बिना पूरी तरह से अच्छी तरह से रहते हैं। आप तय करें।

PRIMARY KEYInnoDB से छुटकारा पाना एक बड़ी गलती है। दूसरी ओर, सरोगेट से छुटकारा पाने AUTO_INCREMENTऔर एक "प्राकृतिक" पीके से बने एक (या अधिक) कॉलम का उपयोग करना अक्सर सही काम होता है। एक साधारण, सामान्य, मामला एक है: कई मानचित्रण तालिका, जैसा कि यहां चर्चा की गई है

व्यक्तिगत अनुभव के आधार पर, मेरा सुझाव है कि तालिकाओं के 2/3 टोपी ऑटो_की पीके के बजाय 'प्राकृतिक' का उपयोग करने के लिए बेहतर हैं।


1
तो ... आप लगभग एक पूर्ण आवेदन पर भरोसा करते हैं क्योंकि यदि कोई डेवलपर DELETEउदाहरण के लिए कोई गलती करता है और आपने DB की ओर से प्रतिबंध नहीं लगाया है तो आप डेटा खो देंगे। यह दृष्टिकोण मान्य है लेकिन इसके लिए गहन कोड और अच्छे परीक्षण की आवश्यकता है, जो उनके पास नहीं है :)
ReynierPM

ऐप में या FK के साथ बहुत ज्यादा डिलीट हो सकता है। बहुत कम हटाना आमतौर पर स्पष्ट हो जाता है। OTOH, मैंने ऐसे मामलों को देखा है जहाँ बहुत कम लागत को नष्ट करना मूल्य है - एक "सामान्यीकरण" के बारे में सोचें जहाँ चीजें शायद ही कभी हटा दी जाती हैं। अतिरिक्त, अप्रयुक्त, पंक्तियाँ वस्तुतः हानिरहित हैं।
रिक जेम्स

मैंने एक मेज पर कोई अनुक्रमणिका के लिए एक 'अच्छा' मामला देखा है - उच्च गति अंतर्ग्रहण के लिए एक मचान तालिका। यह बहुत क्षणिक है (इसलिए InnoDB की आवश्यकता नहीं है) और केवल पूरी तरह से पढ़ने की आवश्यकता है (इसलिए, कोई अनुक्रमित की आवश्यकता नहीं है)।
रिक जेम्स

1
मेरी रैंबलिंग में एक सामान्य विषय पर ध्यान दें: एक भी उत्तर नहीं है; कोई भी आकार-फिट-सभी नहीं।
रिक जेम्स

यदि आप टेबल एक हजार पंक्तियों लंबी हैं; प्रदर्शन कोई मुद्दा नहीं है। यदि आपकी टेबल एक बिलियन पंक्तियाँ हैं, तो सामान्यीकरण, पीके, इंडेक्स, एफके, यूयूआईडी, आदि के बारे में सभी "नियमों" की जांच की जानी चाहिए। एल्ब डीबी पिघल जाएगा।
रिक जेम्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.