यदि, जैसा कि आपकी पोस्ट में कहा गया है, इरादा एक संबंधपरक डेटाबेस (संक्षिप्तता के लिए आरडीबी) बनाने का है, इसलिए, यह उम्मीद की जाती है कि यह इस तरह से कार्य करता है, संक्षिप्त उत्तर है:
- नहीं, आपको डेटा अखंडता बाधाओं की अनदेखी नहीं करनी चाहिए ।
प्राथमिक उद्देश्य प्रासंगिक डेटा का प्रबंधन करना चाहिए क्योंकि यह एक बहुत मूल्यवान संगठनात्मक संपत्ति है, और कहा उद्देश्य प्राप्त करने के लिए एक विश्वसनीय तरीका तकनीकी साधनों को नियोजित करना है जो ध्वनि सिद्धांत पर समर्थित हैं।
इस प्रकार, डेटाबेस पेशेवरों के रूप में, आप व्यावसायिक नियमों को लागू करने के लिए डॉ ईएफ कोड द्वारा आपूर्ति की गई अत्याधुनिक और सुरुचिपूर्ण संबंधपरक मॉडल तंत्र का लाभ उठा सकते हैं , और उन समस्याओं से बच सकते हैं जो अंततः उपयोग नहीं होने पर उत्पन्न होती हैं।
इस संबंध में, मैं (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 ने अपने उत्तर में उल्लेख किया है , कभी-कभी एक क्वेरी का (तार्किक) पुनर्लेखन एक बार फिर से इसकी (भौतिक) निष्पादन योजना को डेटा रीडिंग / राइटिंग को तेज करता है, जो एक कारक है जिसे निश्चित रूप से ध्यान में रखा जाना चाहिए।