15

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

मुझे लगता है कि यह कई उप सवालों में गिर जाएगा:

  1. जब रेफेरेंन्शिअल सत्यनिष्ठा उपयुक्त नहीं है?
  2. क्या यह विदेशी कुंजी की सूची के एकाधिक और/या संभावित अपूर्ण सबसेट वाले फ़ील्ड होना उचित है?
  3. आमतौर पर, क्या यह स्कीमा संरचना डिज़ाइन निर्णय या इंटरफ़ेस डिज़ाइन निर्णय होना चाहिए? (या संभवतः न तो या दोनों)

विचार?

+1

ब्याज की बात के रूप में - रेफरेंसियल अखंडता के प्रदर्शन पर प्रभाव पड़ता है? उदाहरण के लिए: आरआई बंद होने के साथ बंद होने के साथ आवेषण और अपडेट तेज हो जाएंगे? –

+0

@ आहार: अच्छा बिंदु। इस तरह के "लागत/लाभ विश्लेषण" में लागत स्पष्ट होनी चाहिए। –

उत्तर

18

रेफरेंसियल अखंडता कब उचित नहीं है?

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

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

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

आमतौर पर, क्या यह स्कीमा संरचना डिज़ाइन निर्णय या इंटरफ़ेस डिज़ाइन निर्णय होना चाहिए? (या संभवतः न तो या दोनों)

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

बस मेरे विचार।

+1

+1 डेटा गोदामों का उल्लेख करने, लॉगिंग और अलग सिस्टम को जोड़ने के लिए +1। – JKG

+2

बस उत्सुक। यदि आपके पास संदर्भ अखंडता वाला केवल-पढ़ने वाला डेटाबेस है, तो यह किसी भी ओवरहेड में कैसे योगदान देता है?मैं इस धारणा के तहत था कि आरआई के साथ अधिकतर ओवरहेड अपडेट/डिलीट ऑपरेशन से संबंधित था। – Kimble

+3

@ किम्बले: इसमें शामिल किसी भी इंडेक्स के लिए स्टोरेज ओवरहेड योगदान देता है। –

2
  1. कभी नहीं, हालांकि नोएसक्यूएल में कुछ लोग, बहु-मूल्य, और ओओ-डीबी क्षेत्र अलग-अलग महसूस करेंगे। उन्हें मत सुनो, वे गलत हैं।
  2. हां। उदाहरण के लिए, यदि वाहन को विशिष्ट रूप से (लॉटिड, विन) के रूप में पहचाना जाता है तो लोटिड बहुत सारी तालिका के लिए एक विदेशी कुंजी है। यदि आप बहुत सारी तस्वीरों को ढूंढना चाहते हैं तो आप वाहन_पिक्चर कुंजी (लॉटिड इन (लॉटिड, विन) के सबसेट का उपयोग करके, बहुत सारी टेबल पर वाहन_पिक्चर टेबल में शामिल हो सकते हैं। या, क्या मैं तुम्हें समझ नहीं रहा हूँ?
  3. स्कीमा, इंटरफ़ेस दूसरा आता है। यदि स्कीमा खराब है, तो एक अच्छा इंटरफेस रखना एक दीर्घकालिक लक्ष्य नहीं है।
+1

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

7

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

प्रोग्रामिंग कोड बनाम डेटाबेस में डेटा सत्यापन नियम डालने के बारे में तर्क हैं, और मुझे लगता है कि यह आपके सॉफ़्टवेयर के उपयोग मामलों पर निर्भर करता है। यदि एक ही एप्लिकेशन डेटाबेस के लिए एकमात्र रास्ता है, तो आप प्रोग्राम में सत्यापन कर सकते हैं और शायद ठीक हो सकते हैं। लेकिन यदि कई अलग-अलग प्रोग्राम एक ही समय में डेटाबेस का उपयोग कर रहे हैं (उदा। आपका एप्लिकेशन और आपके मित्र का आवेदन), तो आप डेटाबेस में व्यवसाय नियम चाहते हैं ताकि आपका डेटा हमेशा मान्य हो।

'सत्यापन नियम' द्वारा, मैं 'कार्ट में आइटम> 0' जैसे नियमों के बारे में बात कर रहा हूं। आप सत्यापन नियम चाहते हैं या नहीं भी कर सकते हैं। लेकिन मुझे लगता है कि प्राथमिक/विदेशी कुंजी हमेशा महत्वपूर्ण होती हैं (या बाद में आप पाएंगे कि आप चाहते थे कि आप उन्हें लें)। मुझे लगता है कि अगर आप किसी बिंदु पर प्रतिकृति करना चाहते हैं तो उन्हें जरूरी है।

4

संदर्भित, स्केलेबिलिटी और/या अन्य सुविधाओं की लागत पर नहीं आया तो संदर्भित अखंडता हमेशा उपयुक्त होगी।

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

4
  1. रेफरेंसियल अखंडता कब उचित नहीं है?

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

  2. क्या फ़ील्ड में विदेशी कुंजी की सूची के एकाधिक और/या संभावित अपूर्ण सबसेट वाले फ़ील्ड होना उपयुक्त है? इस तरह से

    नकल डेटा सामान्यीकरण की अवधारणा के खिलाफ चला जाता है। इस दृष्टिकोण के लिए फायदे और नुकसान हैं।

  3. आमतौर पर, क्या यह स्कीमा संरचना डिज़ाइन निर्णय या इंटरफ़ेस डिज़ाइन निर्णय होना चाहिए? (या संभवतः न तो या दोनों)

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

संबंधित मुद्दे