एक रिलेशनल डेटाबेस में बाधाएं - उन्हें पूरी तरह से क्यों नहीं हटाया जाए?

Question

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

ORM उपकरण जैसे कि EntityContext, Linq2Data, NHibernate भी खुद से बाधाओं को संभालते हैं, कम से कम आप जानते हैं कि एक दूसरे को किन तालिकाओं की आवश्यकता है। सर्वर के अंदर बाधाओं को करना दो बार एक ही परिवर्तन करने (मजबूर करने) के बारे में है?

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

यह मुझे आश्चर्यचकित करता है और मुझे यकीन नहीं है कि इसे कैसे संभालना है।

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

आप इस परिदृश्य में कैसे कार्य करेंगे?
क्यों नहीं सभी अवरोधों को db से हटाकर आवेदन स्तर पर रखा जाए?

Comments

आप हमेशा एकल ORM टूल के माध्यम से डेटा एक्सेस करने की योजना बना रहे थे? या आप उपयोग में प्रत्येक ORM उपकरण में सभी बाधाओं को सही ढंग से दोहराते हुए "मज़ेदार" होने की योजना बना रहे थे?

— डोना फेलो

पीटर की मेरी नवीनतम टिप्पणी के अनुसार मुझे सहमत होना होगा। कोड आधार (और उन्हें db से हटा दें) के लिए सभी बाधाओं पर भरोसा करने की बात बहुत संकीर्ण थी और संभवतः अल्पकालिक अनुप्रयोगों के लिए पूरी तरह से लागू होती है। शायद कुछ आरएडी डेवलपर्स / परियोजनाओं के लिए भी।

— स्वतंत्र

माइनर नाइटपिक: मुझे लगता है कि तालिकाओं "संबंधों" के बीच विदेशी कुंजी कनेक्शन को कॉल करने पर यह थोड़ा भ्रमित हो जाता है। एक संबंधपरक डेटाबेस में "संबंध" स्वयं टेबल हैं, न कि कनेक्शन। खासकर जब हम तब "रिलेशनल डिज़ाइन" के बारे में बात करते हैं - क्या इसका मतलब तालिकाओं से है, या इसका मतलब विदेशी कुंजी है?

— थॉमस पैडरॉन-मैक्कार्थी

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

— निर्दलीय

आपका डेटाबेस आपके एप्लिकेशन कोड को रेखांकित करने वाला है। इसके अलावा, आपका ओआरएम आपके आवेदन के प्रदर्शन को नुकसान पहुंचा रहा है और एक अच्छा मौका है जिसे आप कम से कम कुछ उपयोग मामलों में बायपास करना चाहते हैं। यदि आप इसे अभी नहीं जानते हैं, तो आप इसे अंततः जान पाएंगे। samsaffron.com/archive/2011/03/30/… । इसके अलावा, सभी बाधाओं को हटाने से आपका डेटाबेस अपनी खुद की अखंडता की रक्षा करने में पूरी तरह से असमर्थ हो जाता है जब यह आपके अलावा अन्य एप्लिकेशन द्वारा दुर्व्यवहार किया जाता है, जो एक्सेल के साथ हॉल को निष्पादित करने के लिए किसी अन्य वास्तविक ऐप से कुछ भी हो सकता है।

— क्रेग

Answer 1

DB से विरोधाभासों को न हटाने के दो सामान्य कारण :

• इसे अभी या भविष्य में और अधिक ऐप्स द्वारा एक्सेस किया जा सकता है , जो ORM का उपयोग कर सकते हैं या नहीं भी कर सकते हैं। यहां तक ​​कि अगर उन ऐप्स के डेवलपर्स ने ईमानदारी से वहां सभी बाधाओं का डुप्लिकेट किया है (जो निचले स्तर के गैर-ओआरएम समाधानों का उपयोग करके काफी कठिन हो सकता है), तो यह हमेशा अतिरिक्त काम होता है। और यदि नहीं, तो भी एक छोटी सी चूक स्कीमा अखंडता को तोड़ने के लिए पर्याप्त है ... जो कुछ ऐसा है जिसे आप जोखिम नहीं लेना चाहते हैं। ज्यादातर कंपनियों में, उनके डीबी में संग्रहीत डेटा उनके व्यवसाय का जीवन है, इसलिए किसी भी तरह से इसकी अखंडता सुनिश्चित की जानी चाहिए। और इसे प्राप्त करने के लिए कोशिश की गई और सिद्ध सर्वोत्तम साधनों को संभव के रूप में DB में कई बाधाओं को लागू करना है।
• क्वेरी ऑप्टिमाइज़र DB स्तर पर ज्ञात बाधाओं पर बहुत निर्भर करता है। यदि आप बाधाओं को दूर करते हैं, तो क्वेरी प्रदर्शन बिगड़ना शुरू हो सकता है । आप तुरंत इसे नोटिस नहीं कर सकते हैं, लेकिन एक दिन यह आपको हिट करने वाला है, और तब तक इसे आसानी से ठीक करने में बहुत देर हो सकती है। चीजों की प्रकृति यह है कि डीबी प्रदर्शन चरम लोड समय पर टूट जाता है, जब सटीक प्रदर्शन माप द्वारा समर्थित सावधानी, अच्छी तरह से सोचा डिजाइन सुधार, और मूल कारणों को इंगित करने के लिए विस्तृत विश्लेषण करने की कम से कम संभावना होती है।

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

Comments

@ जोनास, उसके DB डिजाइन के साथ कथित मुद्दों के बारे में लड़के से बात करते हैं। रिलेशनल और ऑब्जेक्ट ओरिएंटेड दो अलग-अलग दुनिया हैं - न तो प्रति से अधिक दूसरे पर "सुधार" है, और दोनों का अपना स्थान है। संबंधपरक सिद्धांतों पर C # ऐप डिज़ाइन करना उतना ही बड़ा दोष है जितना डीबी ओ ओ मार्ग को डिजाइन करना।

— पेटर तोर्क

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

— Péter Török

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

— इंडिपेंडेंट

"इसे अब या भविष्य में अधिक एप्लिकेशन द्वारा एक्सेस किया जा सकता है।" डेटाबेस के साथ एक समस्या को ठीक करने के लिए कच्चे SQL प्रश्नों को चलाने वाले कुछ डेटाबेस प्रशासक का उल्लेख नहीं है, जबकि उपयोगकर्ता इंतजार कर रहे हैं ...

— थॉमस पैडरन-मैककार्थी

+1: यदि db व्यवसाय डेटा (न कि केवल एप्लिकेशन कॉन्फिगर आदि) संग्रहीत कर रहा है, तो संभावना है कि डेटाबेस लाइव हो जाएगा या वर्तमान ऐप के बाहर बढ़ाया जाएगा 100% तक पहुंच रहा है

— बाइनरी वॉरियर

Answer 2

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

Comments

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

— स्वतंत्र

Answer 3

मुझे परेशान करने वाले सभी बाधाओं को "कैस्केड नहीं" के साथ SQLserver के अंदर कॉन्फ़िगर किया गया है।

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

आपको लगता है कि विकास की आसानी सबसे महत्वपूर्ण बात है। डेटाबेस की दुनिया में यह बस सच नहीं है। डेटा अखंडता प्रदर्शन और डेटा सुरक्षा के बाद सबसे महत्वपूर्ण बात है। यदि प्रश्नों को लिखने में अधिक समय लगता है तो ऐसा हो।

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

Comments

जवाब के लिए धन्यवाद। आपके बारे में बात करने वाली सभी प्रक्रियाओं और एप्लिकेशन प्रकारों को एक डीएएल से बात करनी चाहिए (जिसमें बदले में बाधाएं होंगी)। परंतु! आपकी बात एकदम सही है और आपकी टिप्पणी अच्छी है। सिडेनोट: हाँ। मैं विकास को आसान बनाने के तरीके आजमाता हूं। मेरे लिए, कम जटिलता गलत करने के लिए कम तरीके खड़े कर सकती है। यह "आसान / तेज विकास नहीं करना चाहता है", भले ही यह गलत हो सकता है। इसलिए मैं इस सवाल पोस्ट कर रहा हूँ! मैं किसी को अच्छी भावना भी देखूंगा यदि इस गैर-कैस्केड को इस परिदृश्य के साथ 100% नहीं, बल्कि भावना के साथ धोखा दिया गया था। मुझे इसके कारणों का पता लगाना होगा।

— स्वतंत्र

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

— HLGEM

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

— एचएलजीईएम

Answer 4

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

मेरा दृढ़ विश्वास है कि यह सॉफ्टवेयर डेवलपमेंट का एक ऐसा क्षेत्र है जहाँ आपको DRY नहीं लागू करना चाहिए (और मैं पूरी तरह से उस स्टेटमेंट के डाउनवोट्स की उम्मीद कर रहा हूँ)। आपका डेटा आपके आवेदन का दिल और आत्मा है - अगर यह कभी भी मरम्मत से परे भ्रष्ट है, तो यह है: खेल खत्म। यह IMO लायक है कि वे हर जगह उन बाधाओं को लागू कर सकें जिनकी उन्हें जरूरत है। यदि DB स्तर पर ट्रिगर और बाधाओं के रूप में इसका मतलब है, तो मिडलवेयर पर सर्वर-साइड सत्यापन, और UI पर क्लाइंट-साइड जावास्क्रिप्ट (वेब ​​ऐप्स के लिए), तो यह सुनिश्चित करने के लिए IMO एक आवश्यक बुराई है कि डेटा हमेशा प्राचीन हो। ।

Answer 5

क्या आप जानते हैं ORM का मतलब क्या है? ऑब्जेक्ट-रिलेशनल मैपिंग। विकिपीडिया " असंगत प्रकार प्रणालियों के बीच डेटा परिवर्तित करने की तकनीक" का हवाला देते हुए । हाँ, संबंधपरक और ऑब्जेक्ट मॉडल एक साथ फिट नहीं होते हैं। ORM दोनों प्रकार के सिस्टम के नियमों का सम्मान करते हुए एक बहुत अच्छा रूपांतरण करते हैं। RDBMS इस तरह से आयोजित की जाती हैं, कि आप बाधाओं का उपयोग करके डेटा अखंडता प्राप्त करते हैं। सामान्य तौर पर, अखंडता बहुत अच्छी बात है, इसलिए ऑब्जेक्ट डेटा संग्रहीत करने के लिए डेटा मॉडल बनाते समय ORM उनका उपयोग करते हैं। आपके ORM के पास संभवतः "नॉन कैस्केडिंग" बाधाओं का उपयोग करने का एक अच्छा कारण है। और यदि यह आपको कुछ ऑब्जेक्ट बनाने / अपडेट करने / छोड़ने के बजाय जटिल प्रश्न करने के लिए मजबूर करता है, तो आपके ORM सेटअप में कुछ गड़बड़ है।

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

Comments

विषय डीबी से बाधा कार्यक्षमता को बाहर निकालने और कोड आधार (जैसे .net बोलना: इकाई / Linq2Sql) के भीतर सेटिंग्स / विकास पर भरोसा करते हैं।

— निर्दलीय

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

— जसेक प्रूशिया

ले जाया गया! गिराया नहीं। मैं समझता हूँ कि आपको इस प्रश्न के बारे में खेद है, जिसके बारे में यह नहीं था।

— इंडिपेंडेंट

आप वास्तव में असंगत प्रणालियों के बीच कुछ भी स्थानांतरित नहीं कर सकते। आप DB बाधाओं को छोड़ने जा रहे हैं, आवेदन बाधाओं का परिचय देंगे और केवल आशा करेंगे कि वे वही काम करेंगे (जो सही होने के साथ-साथ गलत भी हो सकता है)। वैसे भी मेरी ईमानदार आशंका अगर मैंने आपके सवाल को गलत समझा।

— जेसेक प्रूशिया

धन्यवाद! "मूव" का मतलब होता है लैटररी "मूव"। जिसका अर्थ है कि आप हर सिस्टम पर एप्लिकेशन (अच्छी अभिव्यक्ति) का निर्माण करते हैं। कम से कम प्रत्येक प्रणाली जो समान DAL को साझा नहीं कर सकती है। एक बहुत अच्छा उदाहरण एक db व्यवस्थापक से प्रत्यक्ष प्रश्न थे कि "कुछ ठीक करें"। कोई डीबी बाधाओं और डिजाइन ज्ञान की कमी के परिणामस्वरूप अनाथ डेटा या व्हाटस, पूरी तरह से डेटा का मजाक उड़ाया जा सकता है।

— निर्दलीय

Answer 6

ठीक है कि ईबे ने क्या किया और उनके पास संभवतः दुनिया के सबसे बड़े डेटाबेस में से एक है:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

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

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

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

Comments

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

— स्वतंत्र

हाँ और मत भूलना - मत भूलना - कि eBay, फेसबुक और अमेज़ॅन की तरह - 99.99% डेटाबेस से बड़ा है, और उनके लिए जो अच्छा है वह संभवतः आपके डेटाबेस के लिए अच्छा है।

— टोनी एंड्रयूज

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

— HLGEM

यदि आपके पास पर्याप्त समय, विशेषज्ञता और पैसा है तो आप अंततः किसी विशिष्ट आवश्यकता को पूरा करने के लिए किसी भी RDBMS, वेब सर्वर या ऑपरेटिंग सिस्टम को प्रोग्राम कर सकते हैं।

— जेफओ

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

— क्रेग

Answer 7

पहला - मेरा जवाब: नहीं, आपको अपने डेटा की देखभाल के लिए अकेले आवेदन पर भरोसा नहीं करना चाहिए।

यह एक बड़ी बहस की ओर इशारा करता है: ओआरएम ने "प्रत्यक्ष" डीबी इंटरैक्शन के लिए तिरस्कार की संस्कृति को प्रोत्साहित किया है, अक्सर सामान्यीकरण / संदर्भात्मक अखंडता की कीमत पर। संबंधपरक मॉडल में निहित डिजाइन की कीमत पर टेबल्स को जबरन ऑब्जेक्ट मनमानी वस्तुओं से मैप किया जाता है। OOP द्वारा इष्ट डिकोडिंग को यकीनन यहां बलिदान किया गया है क्योंकि एप्लिकेशन इसे डिज़ाइन करता है जो डेटा संरचना में महसूस किया गया है। जबकि ORM ने बड़ी उपयोगिता का प्रदर्शन किया है, यह SQL के दुरुपयोग या अविश्वास पर आधारित लगता है।

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

मैं @ जेसेक प्रुशिया से सहमत हूं - मुझे लगता है कि ORM RDBMS के लिए एक बुरा मैच है, मैं व्यक्तिगत रूप से RDBMS पर DBAL का विकल्प चुनूंगा, या ORM के साथ OODB के लिए जाऊंगा।

Comments

विषय के विकल्प बोलने के लिए +1। बहस का दूसरा पक्ष निश्चित रूप से है: "कुछ डेटा कितना बुरा होगा?" और उत्तर किसी के पास मिलियन डॉलर के बैंक खाते में धन को रद्द करने या अरब डालने का हो सकता है। साथ ही कुछ अनाथ डेटा जो अच्छी सफाई दिनचर्या के साथ हटा दिए जाते हैं। इस विषय का सारांश, लचीलेपन की लागत की स्थिरता की तरह दिखता है। जो पूरी तरह से db की सामग्री और उपयोग की गंभीरता पर निर्भर करता है।

— स्वतंत्र

Answer 8

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

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

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

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

Answer 9

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

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

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

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

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

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

Comments

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

— स्वतंत्र

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

— क्रेग