क्या बड़े अनुप्रयोगों के लिए एक ही डेटाबेस में एक अलग स्कीमा में टेबल पर विदेशी कुंजी बनाना बुरा है?

Question

मैं समर्पित सर्वर के लिए एक बड़ा pl / sql वेब-आधारित एप्लिकेशन ट्रांसफर पर काम कर रहा हूं। यह एप्लिकेशन प्रोग्राम कोड के 70 पैकेजों के साथ एक स्कीमा में स्थित है। इस एप्लिकेशन को लगभग 15 लोगों ने अलग-अलग समय में बनाया था। और यह अलग-अलग स्कीमाओं में संदर्भ तालिकाओं पर विदेशी कुंजी बनाने के लिए हमारे लिए सामान्य अभ्यास था क्योंकि यह वास्तव में आश्वस्त है और डेटाबेस को बहुत साफ रखता है, क्योंकि हमें अलग-अलग स्कीमा में समान रेफ़रेंस टेबल रखने की आवश्यकता नहीं है।

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

क्या एक बड़े एप्लिकेशन के साथ ऐसा करना वास्तव में बुरा है?

Comments

आपका डीबीए बर्खास्त किया जाना चाहिए।

— कॉलिन 'टी हार्ट

हम सभी चिल्ला रहे हैं कि आपका डीबीए एक मूर्ख है अगर यह सब उन्होंने कहा है, लेकिन क्या आप सुनिश्चित हैं कि आपके डीबीए के तर्क के लिए कोई अन्य संदर्भ नहीं था?

— कर्मी

हो सकता है कि डीबीए इस काम के निर्माण में किए गए हास्यास्पद काम का समर्थन करने के लिए सिर्फ सबसे अच्छा काम कर रहा हो।

— स्वैसे

@swasheck दूसरी ओर, क्या आप इस DBA के तहत डेटाबेस में कई वर्षों की विसंगतियों को जमा करने के बाद उसकी नौकरी करना चाहते हैं?

— ट्विंकल्स

@Twinkles बिल्कुल नहीं

— स्वैसे

Answer 1

मेरे साथ - मैं SQL सर्वर से आता हूं और ओरेकल से नफरत करता हूं, लेकिन मुझे लगता है कि तर्क अभी भी खड़ा है।

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

जैसे, मुझे लगता है कि डीबीए की आवश्यकता अक्षमता का संकेत है। कृपया कोई भी इसमें कदम रख सकता है और प्रतिवाद प्रदान कर सकता है - मुझे खुशी होगी। लेकिन यह है कि मैं इसे SQL सर्वर पर कैसे करता हूं (हालांकि, फिर से, स्कीमा की हमारी परिभाषा IIRC है जो ओरेकल परिभाषा से अलग है)।

Answer 2

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

Oracle में आप वर्तमान स्कीमा के बाहर की वस्तुओं के लिए SYNONYMS बनाकर इस समस्या को हल करते हैं।

Comments

आप पर्यायवाची शब्दों का प्रयोग कर सकते हैं और "यह क्या संदर्भित करता है?" के प्रश्न को और अधिक गन्दा कर सकते हैं। सुरक्षा, प्रदर्शन और सर्वोत्तम प्रथाओं के बारे में अधिक जानकारी के लिए यहाँ देखें stackoverflow.com/a/10042117/851930

— kevinsky

समानार्थी शब्द का उपयोग विदेशी कुंजी बाधाओं के लक्ष्य के रूप में नहीं किया जा सकता है।

— कॉलिन टी हार्ट 15

मान्य अंक। और आगे सबूत है कि दूसरों को गुण और खतरों का तर्क देने के बिना बयान देना बुरा है।

— ट्विंकल्स

Answer 3

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

Answer 4

एकमात्र "बुरा विचार" जिसे मैं ऐसा करने की कल्पना कर सकता हूं, यह है कि आप किसी भूमिका के लिए संदर्भ ऑब्जेक्ट विशेषाधिकार (एक बाधा बनाने के लिए आवश्यक है जो किसी तालिका को संदर्भित करता है) को मंजूरी नहीं दे सकते। मुझे स्कीमा / उपयोगकर्ता द्वारा स्कीमा / उपयोगकर्ता किया जाना है।

इसके अलावा, मुझे आपके DBA की बात दिखाई नहीं दे रही है।

Answer 5

ज़रा इस बारे में सोचें: चाइल्ड टेबल ओनर स्कीमा अपनी तालिका में रिकॉर्ड बनाना शुरू करता है और अनजाने में पेरेंट टेबल स्कीमा उपयोगकर्ता को पेरेंट टेबल से रिकॉर्ड हटाने से रोकता है। क्या यह कुछ ऐसा है जो इसकी आशंका और सराहना करता है?