क्या मुझे डेटाबेस में या कोड में तालिकाओं के बीच संबंधों को परिभाषित करना चाहिए?


60

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

डेटाबेस में:

  • डिजाइन से सही डेटा। एप्लिकेशन त्रुटियों को रोकें जो अमान्य डेटा का कारण बन सकती हैं।

  • डेटा को सम्मिलित / अद्यतन करते समय एप्लिकेशन के लिए नेटवर्क राउंड ट्रिप को कम करें क्योंकि डेटा अखंडता की जांच करने के लिए एप्लिकेशन को अधिक क्वेरी (एस) करनी होती है।

स्रोत कोड में:

  • अधिक लचीला।

  • बेहतर जब कई डेटाबेस के लिए स्केलिंग, कभी-कभी संबंध क्रॉस-डेटाबेस हो सकता है।

  • डेटा अखंडता पर अधिक नियंत्रण। डेटाबेस को हर बार यह जांचने की आवश्यकता नहीं होती है कि एप्लिकेशन डेटा को संशोधित करता है (जटिलता हो सकती है O (n) या O (n log n) (?))। इसके बजाय, इसे आवेदन के लिए सौंप दिया गया है। और मुझे लगता है कि एप्लिकेशन में डेटा अखंडता को संभालने से डेटाबेस का उपयोग करने की तुलना में अधिक वर्बोस त्रुटि संदेश हो जाएंगे। उदाहरण: जब आप एक एपीआई सर्वर बनाते हैं, यदि आप डेटाबेस में संबंधों को परिभाषित करते हैं, और कुछ गलत हो जाता है (जैसे संदर्भित इकाई मौजूद नहीं है), तो आपको एक संदेश के साथ एक SQL अपवाद मिलेगा। ग्राहक को 500 वापस करने का सरल तरीका यह होगा कि "आंतरिक सर्वर त्रुटि" है और ग्राहक को पता नहीं होगा कि क्या गलत है। या सर्वर यह पता लगाने के लिए संदेश को पार्स कर सकता है कि क्या गलत है, जो मेरी राय में एक बदसूरत, त्रुटि-रहित तरीका है। यदि आप एप्लिकेशन को इसे संभालने देते हैं,

क्या कुछ और है?

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

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


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

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

10
उल्लेख के लायक कुछ ... एक बार जब आप अपने डेटाबेस में अखंडता की समस्याओं का परिचय देते हैं तो यह पेंडोरा के बॉक्स को खोलने के लिए एक परिजन है। यह विसंगति-रोधी डेटाबेस के लिए अखंडता को फिर से प्रस्तुत करने के लिए एक बुरा सपना है। अपने डेटाबेस पर नियंत्रण रखना एक परेशानी हो सकती है लेकिन यह आपको लंबे समय में बहुत दर्द से बचाएगा।
DanK

3
स्रोत कोड में: आप अंततः एक डेटाबेस के अधिकांश लेखन को समाप्त करते हैं।
Blrfl

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

जवाबों:


70

टीएल; डीआर: रिश्ते की बाधाओं को डेटाबेस में जाना चाहिए।


आपका आवेदन काफी बड़ा नहीं है।

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

मैं, हालांकि, आपको पहले बताए गए डेटाबेस सॉफ़्टवेयर के प्रलेखन की जांच करनी चाहिए, और मौजूदा उत्पाद ऑफ़र की जांच करनी चाहिए। उदाहरण के लिए, Postgres और MySQL के शीर्ष पर क्लस्टरिंग ऑफ़र हैं।

और यहां तक ​​कि अगर आप आवेदन में कुछ सत्यापन की आवश्यकता को समाप्त करते हैं, तो बच्चे को स्नान के पानी से बाहर न डालें । आखिरकार, आपको जितना कम करना होगा, आप उतना ही बेहतर होंगे।

अंत में, यदि आप भविष्य के स्केलेबिलिटी के मुद्दों के बारे में चिंतित हैं, तो मुझे डर है कि आपके आवेदन को किसी भी तरह से स्केल करने से पहले महत्वपूर्ण परिवर्तनों से गुजरना होगा। अंगूठे के एक नियम के रूप में, हर बार जब आप 10x बढ़ते हैं, तो आपको फिर से डिजाइन करना होगा ... तो चलिए स्केलेबिलिटी के मुद्दों का अनुमान लगाने में असफल होने में बहुत अधिक पैसा नहीं डूबता है, और इसके बजाय पैसे का उपयोग वास्तव में उस बिंदु तक पहुंचने के लिए करें जहां आपके पास उन मुद्दे हैं।

आपका एप्लिकेशन पर्याप्त रूप से सही नहीं है।

क्या मौका है कि आपके द्वारा उपयोग किए जाने वाले डेटाबेस में चेक के दोषपूर्ण कार्यान्वयन की संभावना है कि आपके आवेदन में चेक का दोषपूर्ण कार्यान्वयन है?

और कौन सा आप सबसे अधिक बार बदलते हैं?

मैं किसी भी समय डेटाबेस के सही होने पर शर्त लगाता हूँ ।

आपके डेवलपर्स पर्याप्त वितरित नहीं सोच रहे हैं।

डेटा डालने पर एप्लिकेशन के लिए नेटवर्क राउंड ट्रिप को कम करें क्योंकि डेटा अखंडता की जांच के लिए एप्लिकेशन को अधिक क्वेरी (एस) करनी होती है।

लाल झंडा ! 1

यदि आप सोच रहे हैं:

  • जाँच करें कि क्या रिकॉर्ड मौजूद है
  • यदि नहीं, तो रिकॉर्ड डालें

तब आप सबसे बुनियादी समसामयिक मुद्दे पर विफल रहे : एक और प्रक्रिया / धागा हो सकता है कि आप जाते ही रिकॉर्ड जोड़ रहे हों।

यदि आप सोच रहे हैं:

  • जाँच करें कि क्या रिकॉर्ड मौजूद है
  • यदि नहीं, तो रिकॉर्ड डालें
  • जाँच करें कि रिकॉर्ड डुप्लिकेट के रूप में डाला गया था या नहीं

तब आप MVCC के लिए खाते में विफल रहे: आपके पास उस डेटाबेस का दृश्य जो आपके लेनदेन के शुरू होने के समय स्नैपशॉट है; यह उन सभी अपडेट को नहीं दिखाता है जो घटित हो रहे हैं, और शायद प्रतिबद्ध भी नहीं हैं।

कई सत्रों में बाधाओं को बनाए रखना वास्तव में एक कठिन समस्या है, खुशी है कि यह आपके डेटाबेस में हल है।

1 जब तक आपका डेटाबेस ठीक से सीरियल करने योग्य संपत्ति को लागू नहीं करता है; लेकिन कुछ वास्तव में करते हैं।


लास्ट:

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

त्रुटि संदेशों को पार्स न करें , यदि आप किसी भी उत्पादन-ग्रेड डेटाबेस का उपयोग करते हैं तो इसे संरचित त्रुटियों को वापस करना चाहिए। संभवतः कुछ गलत है, यह इंगित करने के लिए आपके पास कुछ त्रुटि कोड होगा, और इस कोड के आधार पर आप एक उपयुक्त त्रुटि संदेश तैयार कर सकते हैं।

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

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

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


3
हाहा, आपने यह लिखा है जैसा कि मैं अपनी टिप्पणी लिख रहा था, विडंबना यह है कि हम दोनों जो बिंदु बना रहे हैं उस पर जोर दे रहे हैं। मैं पूरी तरह सहमत हूं: आप गैर DB कोड में अखंडता या बाधाओं को भी नहीं कर सकते। लेन-देन दूसरों के परिणामों को तब तक नहीं देख सकते जब तक वे प्रतिबद्ध नहीं हैं (और तब भी शायद नहीं)। आप अखंडता का भ्रम प्राप्त कर सकते हैं, लेकिन यह समय के कारण या ताले के कारण गंभीर स्केलेबिलिटी के मुद्दों के अधीन है। केवल डेटाबेस ही इसे सही ढंग से कर सकता है।
LoztInSpace

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

1
@ काट 11: यह सच है। और आत्म-वर्णन का भी लाभ है कि उपकरण आसानी से डेटा को समझ सकते हैं और उस पर कार्य कर सकते हैं, जो कभी-कभी उपयोगी हो सकता है।
Matthieu M.

1
MVCC के बारे में आपका तर्क DBs में सटीक नहीं है, जो SERIALIZABLE अलगाव को सही ढंग से लागू करता है (उदाहरण के लिए, पोस्टग्रैसीक्यू के आधुनिक संस्करण - हालांकि कई प्रमुख RDBMS नहीं करते हैं)। इस तरह के डीबी में, यहां तक ​​कि पहली, भोली, दृष्टिकोण सही ढंग से काम करेगा - अगर संघर्ष लिखते हैं, तो उन्हें क्रमिक विफलता के रूप में वापस ले लिया जाएगा।
जेम्स_पिक

1
डीबी में जो कि SERIALIZABLE को सही ढंग से लागू करते हैं, यदि आप सभी सफलतापूर्वक किए गए लेन-देन करते हैं, तो कुछ ऑर्डरिंग (जो कि दीवार-घड़ी ऑर्डरिंग के समान नहीं हो सकती है), जैसे कि यदि आपने उन सभी को क्रमिक रूप से चलाया (बिना किसी संगति के) उस क्रम में, सभी परिणाम बिल्कुल समान होंगे। यह सही पाने के लिए मुश्किल है, और एसक्यूएल चश्मा पर्याप्त अस्पष्ट हैं कि आप अपने आप को समझा सकते हैं कि यह सीरियल स्तर पर लिखने की अनुमति देने के लिए ठीक है, इसलिए कई DB विक्रेता SERIALIZABLE को SNAPSHOT अलगाव (मैं आपको Oracle के रूप में देख रहा हूं) के रूप में व्यवहार करता हूं।
जेम्स_पिक

119

हर बार एप्लिकेशन डेटा को संशोधित करने के लिए डेटाबेस को डेटा अखंडता के लिए जांचना नहीं पड़ता है।

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


5
@ dan1111 मुझे आपकी टिप्पणी समझ में नहीं आ रही है ... क्या आप कह रहे हैं: डेटाबेस द्वारा सरल बाधाओं को लागू किया जाता है, इसलिए वे आवेदन कोड के लिए कोई समस्या नहीं हैं, अधिक जटिल बाधाओं को लागू करना बहुत कठिन है, इसलिए बस उन पर हार मान लें? या आप कह रहे हैं कि डेटाबेस ट्रिगर (और समान तंत्र) का उपयोग करके जटिल बाधाओं को लागू करना बहुत जटिल है और इसलिए उन्हें आवेदन कोड में लागू करना बेहतर है?
बकुरीउ

47
आप गैर DB कोड में अखंडता या बाधाओं को भी नहीं कर सकते। लेन-देन दूसरों के परिणामों को तब तक नहीं देख सकते जब तक वे प्रतिबद्ध नहीं हैं (और तब भी शायद नहीं)। आप अखंडता का भ्रम प्राप्त कर सकते हैं, लेकिन यह समय के कारण या ताले के कारण गंभीर स्केलेबिलिटी के मुद्दों के अधीन है। केवल डेटाबेस ही इसे सही ढंग से कर सकता है।
12 मई को LoztInSpace

17
Anecdotally, @ LoztInSpace की टिप्पणी का अनुसरण करने के लिए, मैंने एक बार एक (भयानक) कंपनी के लिए काम किया था, जहाँ उस टेबल में से एक को इस तरह से सेट किया गया था कि DB ऑटो को ID बढ़ाने के बजाय, आवेदन ने अंतिम बार ID लिया इसमें एक जोड़ा और नई आईडी के रूप में इस्तेमाल किया। दुर्भाग्य से, एक सप्ताह के बारे में एक बार डुप्लिकेट आईडी डालने के लिए एक दुर्घटनाग्रस्त दुर्घटनाग्रस्त आवेदन लाया गया था ..
Trotski94

9
@ dan1111 आप कभी भी एप्लिकेशन में बग नहीं लिखते हैं, है ना?
user253751

4
@DavidPacker मैं सहमत हो सकता हूं, हालांकि एक बार जब आपके पास डेटाबेस तक पहुंचने वाले कई क्लाइंट होते हैं, तो आप केवल डेटाबेस में बाधाओं को लागू कर सकते हैं । जब तक, कि आप पंक्तियों के बजाय तालिकाओं के बजाय तालिकाओं को बंद करना शुरू कर देते हैं, तो उस प्रदर्शन को हिट करता है।
आइकर

51

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

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

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

यह वह जगह है जहाँ डेटाबेस स्तर की अखंडता आपके बेकन को बचाएगा।


इसके अलावा, उस डेवलपर की तस्वीर लें जो आपके जाने के बाद इस कंपनी में आपकी भूमिका लेता है और फिर डेटाबेस में बदलाव करने का काम सौंपा जाता है।

क्या वह आपसे नफरत करेगा अगर डेटाबेस में कोई FK बाधाएं नहीं हैं ताकि वह यह बता सके कि उसे बदलने से पहले एक टेबल में कौन से रिश्ते हैं? ( सुराग, जवाब हां में है )


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

9
@nikonyrh मैं ऐसा नहीं करूंगा। अड़चनें इतनी हैं कि अनुप्रयोग निरंतर डेटा पर भरोसा कर सकते हैं। FK को निष्क्रिय करने के लिए 'पागलपन' में इसे प्राप्त करना है।
धान

5
माना। इसके अलावा, भले ही आपका आवेदन एकमात्र ग्राहक हो, आपके पास आपके आवेदन के विभिन्न संस्करण हो सकते हैं जो थोड़े अलग अवरोधों को लागू करने का प्रयास करते हैं। आमतौर पर, प्रफुल्लितता का आनंद (ठीक है, वास्तव में नहीं है। यह 'प्रफुल्लितता' की तुलना में 'अराजकता और पूरी तरह से हताशा' की तरह है)।
आइकर

5
मैं इस पर पूरी तरह से गौर कर सकता हूं। मेरे मामले में मैं MyISAM पर अटक गया था जो वास्तव में विदेशी कुंजी का समर्थन नहीं करता है, इसलिए मैंने 250GB डेटा को अखंडता के साथ लागू किया। जब यह अधिक व्यावहारिक आकार के लिए बैकलॉग प्राप्त करने के लिए डेटा छंटाई शुरू करने के लिए आया था, और जब यह स्पष्ट हो गया कि आवेदन खुद को इस सब को संभालने में सक्षम नहीं होने जा रहा है, तो अराजकता फैल गई। मुझे नहीं पता कि मैं पिछले तनाव का उपयोग क्यों कर रहा हूं; यह अभी भी हो रहा है और समस्या (दो साल) अभी भी हल होना बाकी है। * सूँघना *
हल्की

1
मेरा तर्क है कि एक सभ्य कोड आधार को आपके आवेदन से दृढ़ता परत का उपयोग करते हुए एक-एक स्क्रिप्ट लिखना आसान होना चाहिए, कम से कम कच्ची एसक्यूएल लिखने के लिए जितनी जल्दी हो सके। One अपने एप्लिकेशन के कोड को संशोधित करना ’ कभी भी एकबारगी स्क्रिप्ट के लिए आवश्यक नहीं होना चाहिए ।
जोनाथन ने

17

डेटाबेस में आपके संबंध होने चाहिए।

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

यदि आपको कभी अतिरिक्त लचीलेपन की आवश्यकता होती है - जैसे कि आपके विख्यात क्रॉस डेटाबेस संदर्भ - तो आप बाधाओं को जानबूझकर और विचार के साथ हटा सकते हैं। आपके डेटाबेस के भीतर स्थिरता होने का मतलब है कि आपके पास उन बाधाओं को संशोधित करने और संदर्भात्मक अखंडता की निश्चितता का विकल्प है।


1
सच। मुझे यह कहना चाहिए था कि कंस्ट्रक्शन चेकिंग के प्रदर्शन को डेटाबेस की तुलना में एप्लिकेशन में बेहतर तरीके से हैंडल किया जाएगा।
कर्क ब्रॉडहर्स्ट

13
  • हम अब एक बैक-एंड <-> एक फ्रंट-एंड वर्ल्ड में नहीं रहते हैं।
  • अधिकांश समाधानों में एक वेब फ्रंट-एंड, एक मोबाइल फ्रंट-एंड, एक बैच-फ्रंट-एंड और iPad फ्रंट-एंड आदि शामिल हैं।
  • डेटाबेस इंजन में पहले से ही कोड के हजारों परीक्षण किए गए लाइन हैं जो कि संदर्भात्मक अखंडता को लागू करने के लिए अनुकूलित हैं।

जब आप डोमेन समस्या को हल करने के लिए कोड लिखने के लिए क्या आप वास्तव में संदर्भात्मक अखंडता कोड को लिखना और परीक्षण कर सकते हैं?


2
"हम अब एक बैक-एंड <-> एक फ्रंट-एंड वर्ल्ड में नहीं रहते।" क्या हमने कभी? कुछ साल पहले, मैंने एक डेटाबेस सिस्टम पर काम किया था जिसमें कम से कम दो दर्जन अलग-अलग भाषाओं में लिखे प्रोग्राम थे जो इसे एक्सेस कर रहे थे। 1970 के दशक में कुछ कार्यक्रमों की पहली रिलीज हुई थी।
माइक शेरिल 'कैट रिकॉल'

2

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

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

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


1

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

डुप्लिकेट कोड

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

प्रयास है

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

दक्षता

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

नियंत्रण

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

पॉइंटिंग बंद करना

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

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


1
यदि लोग अच्छी तरह से सोचे गए उत्तरों को कम कर देते हैं क्योंकि यह उनकी हठधर्मिता से असहमत है, तो एसई स्टैकएक्सचेंज एक बुरा स्थान बन जाता है।
कार्ल लेथ

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

1
"डेटाबेस कोड में लिखे गए हैं। कुछ भी जादू नहीं है जो वे करते हैं जो आप अपने कोड में नहीं कर सकते।" , नहीं, आप आवेदन कोड में संदर्भ अखंडता लागू नहीं कर सकते हैं (और यदि आपको इसे लागू करने की आवश्यकता नहीं है, तो आप एक डेटाबेस सर्वर का उपयोग क्यों कर रहे हैं?)। यह नहीं है कि कोड क्या कर सकता है, यह इस बारे में है कि यह कहाँ किया जा सकता है।
हाइड

0

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

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

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

अपने बिंदुओं को देखते हुए, विशेष रूप से क्रॉस-डेटाबेस संदर्भ । उस स्थिति में, हाँ, RDBMS में ही लागू सेवा में संदर्भ नहीं होना चाहिए। लेकिन इस तरह से पालन करने से पहले, डिजाइन के दौरान पहले से ही इस पर विचार करना बेहतर नहीं होगा?

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

आप यह भी इंगित कर रहे हैं कि कोड में इसे लागू करना अधिक लचीला है । ठीक है, लेकिन उस आवाज़ की तरह नहीं है जैसे आप एक अधूरे डिजाइन के साथ काम कर रहे हैं? अपने आप से पूछें, आपको अधिक लचीलेपन की आवश्यकता क्यों है?

DB में अखंडता जांच के कारण प्रदर्शन का मुद्दा वास्तविक नहीं है। RDBMS आपके द्वारा किसी भी कार्यान्वयन की तुलना में बहुत तेज़ी से ऐसी चीज़ों की जाँच कर सकता है। क्यों? ठीक है, आपको मीडिया के विघटन से निपटना होगा, आरडीबीएमएस नहीं करता है। और यह अपने आँकड़ों का उपयोग करके ऐसी जाँचों को अनुकूलित कर सकता है

तो आप देखते हैं, यह सब डिजाइन करने के लिए वापस आता है। बेशक आप अब कह सकते हैं, लेकिन क्या होगा अगर एक अज्ञात आवश्यकता दिखाई दे रही है, गेम चेंजर? हां यह हो सकता है, लेकिन इस तरह के बदलावों को डिजाइन और नियोजित किया जाना चाहिए। ; ओ)


0

आपके पास कुछ बहुत अच्छे उत्तर हैं लेकिन कुछ और बिंदु हैं

डेटा अखंडता वह है जो एक डेटाबेस को करने के लिए डिज़ाइन किया गया है

आवेदन स्तर पर FK डिलीट की तरह उचित कंसीडर करना भयावह होगा

डेटा अखंडता में विशेषज्ञता एक डीबीए के साथ है

प्रोग्राम स्तर पर आप सम्मिलित करें, अपडेट करें, बल्क अपडेट, बल्क इंसर्ट, बल्क डिलीट करें ...
पतले ग्राहक, मोटे ग्राहक, मोबाइल ग्राहक ....
डेटा अखंडता एक प्रोग्रामर की विशेषज्ञता नहीं है - बहुत सारे डुप्लिकेट कोड और कोई गड़बड़ करेगा यह ऊपर है

कहते हैं कि आप हैक हो गए हैं - आप किसी भी तरह से मुसीबत में हैं लेकिन एक हैकर एक छोटे से छेद के माध्यम से बहुत नुकसान कर सकता है अगर डेटाबेस में कोई अखंडता सुरक्षा नहीं है

आपको SQL या TSQL के माध्यम से सीधे डेटा में हेरफेर करने की आवश्यकता हो सकती है
कोई भी सभी डेटा नियमों को याद रखने वाला नहीं है


0

आपके प्रश्न का कोई मतलब नहीं है: यदि आप डेटाबेस को बदल सकते हैं, तो यह कोड है, यदि आप डेटाबेस को नहीं बदल सकते हैं, तो आपको कहीं और अपनी बाधाओं को बनाना होगा।

एक डेटाबेस जिसे आप बदल सकते हैं वह हर बिट कोड जितना रूबी, जावास्क्रिप्ट, c # या ada की किसी भी लाइन के रूप में है।

आपके सिस्टम में बाधा डालने के लिए प्रश्न को विश्वसनीयता, लागत और विकास में आसानी के लिए उबालना चाहिए।


0

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.