Dbo स्कीमा से बचना चाहिए?


29

जब यह dbo स्कीमा की बात आती है:

  • डेटाबेस ऑब्जेक्ट बनाते समय dbo स्कीमा का उपयोग करने से बचने के लिए क्या यह सबसे अच्छा अभ्यास है?
  • डीबीओ स्कीमा को क्यों टाला जाना चाहिए या इसे लागू करना चाहिए?
  • कौन सा डेटाबेस उपयोगकर्ता dbo स्कीमा का मालिक होना चाहिए?

कुछ सलाहकारों ने कहा कि डीबो स्कीमा से बचने के लिए यह अच्छा अभ्यास है और हमेशा उपयोगकर्ता परिभाषित स्कीमा बनाते हैं और इन स्कीमा में objets असाइन करते हैं।
जरा

मुझे यह कथन अलेक्जेंडर कुजनेत्सोव के इस ब्लॉग पोस्ट की टिप्पणियों में भी मिला :
jrara

हां, अब इससे बचें। dba.stackexchange.com/a/4109/630 और dba.stackexchange.com/q/8511/630 और stackoverflow.com/q/6502222/27535 @JNK: FYI करें आपके लिए
gbn

जवाबों:


21

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

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

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

मेरा मानना ​​है कि, SQL सर्वर में ऐसे उत्पाद की पेशकश की जाती है जो विभिन्न विभागों द्वारा एक्सेस और क्वेरी की जा सकती है। वास्तव में केवल DBAs / DBDevs ही डेटाबेस तक पहुँचते हैं और यह आमतौर पर केवल एप्लिकेशन डेटा को संग्रहीत करता है।

यह पठनीयता और प्रबंधन क्षमता के साथ भी मदद करता है। पहले ब्लश में मैं आसानी से पहचान सकता हूं कि कौन सी तालिका डेटा रखती है और डेटा को कैसे अलग किया जाता है।

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


6

मुझे लगता है कि यह वास्तव में उपयोगकर्ता वरीयता के लिए आता है क्योंकि ऐसा करने के लिए कोई वास्तविक तकनीकी कारण नहीं है। वास्तव में, सादगी के लिए, मैं कहता हूं कि जब तक आपकी सुरक्षा की आवश्यकताएं पूरी न हो जाएं, तब तक हमेशा डीबीओ का उपयोग करें। बेशक, आप हमेशा इसे केवल संगठनात्मक उद्देश्यों के लिए भी कर सकते हैं।


1
इस दृष्टिकोण के पीछे 100%। मैं अक्सर सादगी के लिए dbo स्कीमा में "कोर" टेबल छोड़ देता हूं और जरूरत पड़ने पर जोड़ना शुरू करता हूं। आमतौर पर मेरे द्वारा जोड़ा गया पहला अलग स्कीमा है "स्टेज" या "स्टेजिंग", मेरे स्टेजिंग टेबल को अलग-अलग करने के लिए। एक अन्य उदाहरण बाहरी स्रोत से डेटा जोड़ना होगा, ट्विटर का कहना है। सभी तालिकाओं (यानी TwitterAccount, TwitterStatus इत्यादि) को उपसर्ग करने के बजाय मैं "ट्विटर" स्कीमा बनाऊंगा।
रोबोपिम

5

यदि कुछ भी हो, तो dbo से बचना चाहिए क्योंकि यह SQL सर्वर के लिए डिफ़ॉल्ट है, यह भी वर्णनात्मक नहीं है। अन्य सभी डिफ़ॉल्ट नामों की तरह, क्योंकि यह पहले से ही ज्ञात है कि यह एक हैकर के जीवन को बहुत आसान बना देता है (हालांकि यदि वे उस बिंदु पर हैं जहां वे सिर्फ आपके स्कीमा नाम का पता लगाने की कोशिश कर रहे हैं तो आप शायद पहले से ही बोर हो गए हैं)।

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

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


1
+1 के लिए "इससे बचें क्योंकि इसका डिफ़ॉल्ट है"। उपयोगकर्ताओं को कम से कम एक वस्तु बनाते समय इसके बारे में कम से कम सोचने के लिए मजबूर करता है।
ब्रैड डिक

4

यह पहले सबसे अच्छा अभ्यास नहीं था क्योंकि एसक्यूएल 2005 से पहले स्कीमा छिपे हुए थे, सब कुछ डोबो स्कीमा में डाल दिया गया था। SQL सर्वर टीम इसे सर्वश्रेष्ठ अभ्यास के रूप में दिखाती है और इसके बारे में एक लेख प्रकाशित करती है: SQL सर्वर सर्वश्रेष्ठ अभ्यास - डेटाबेस ऑब्जेक्ट योजनाओं का कार्यान्वयन

जहां तक ​​आपके अन्य प्रश्न के बारे में है कि इसे किसके पास होना चाहिए: dbo स्कीमा dbo उपयोगकर्ता खाते के स्वामित्व में है।

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