क्या निहित डेटाबेस के नुकसान हैं?

Question

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

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

Answer 1

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

---

कनेक्शन तार

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

---

क्रॉस-डीबी प्रश्न

यहां तक ​​कि अगर आप एक ही उपयोगकर्ता को एक ही सर्वर पर दो अलग-अलग निहित डेटाबेस में एक ही पासवर्ड के साथ बनाते हैं, तो आपका एप्लिकेशन क्रॉस-डेटाबेस क्वेरी नहीं कर पाएगा। उपयोगकर्ता नाम और पासवर्ड एक ही हो सकता है, लेकिन वे कर रहे हैं नहीं एक ही उपयोगकर्ता। इसका कारण? यदि आपके पास किसी होस्ट किए गए सर्वर पर डेटाबेस सम्‍मिलित है, तो आपको उसी सम्‍मिलित उपयोगकर्ता के रूप में होने से नहीं रोका जाना चाहिए जो किसी और को हो सकता है जो उसी होस्ट किए गए सर्वर का उपयोग कर रहा हो। जब पूर्ण नियंत्रण आ जाता है ( SQL सर्वर 2012 के बाद संस्करण में कभी नहीं), क्रॉस-डेटाबेस क्वेरी वैसे भी बिल्कुल निषिद्ध होगी। मैं अत्यधिक, अत्यधिक, अत्यधिक अनुशंसा करता हूं कि आप सर्वर-स्तर लॉगिन को डेटाबेस उपयोगकर्ताओं के समान नाम के साथ न बनाएं और निहित डेटाबेस में समान उपयोगकर्ता नाम बनाने से बचने का प्रयास करें। यदि आपको कई सम्‍मिलित डेटाबेस को क्‍वेरी चलाने की आवश्‍यकता है, तो सर्वर-लेवल लॉगिन का उपयोग करके ऐसा करें जिसमें उचित विशेषाधिकार हैं (आप सोच सकते हैं कि यह है sysadmin, लेकिन केवल-पढ़ने के लिए क्वेरी के लिए, यह है CONNECT ANY DATABASEऔर SELECT ALL USER SECURABLES)।

---

समानार्थक शब्द

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

---

पासवर्ड नीति

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

---

मिलान

चूंकि हम अब tempdb के टकराने पर भरोसा नहीं कर सकते हैं, इसलिए आपको किसी भी कोड को बदलने की आवश्यकता हो सकती है जो वर्तमान में स्पष्ट कॉलेशन का उपयोग करता है या इसके बजाय DATABASE_DEFAULTउपयोग CATALOG_DEFAULTकरता है। कुछ संभावित मुद्दों के लिए इस BOL लेख को देखें ।

---

IntelliSense

यदि आप किसी निहित उपयोगकर्ता के रूप में किसी सम्‍मिलित डेटाबेस से जुड़ते हैं, तो SSMS पूरी तरह से IntelliSense का समर्थन नहीं करेगा। आपको सिंटैक्स त्रुटियों के लिए बुनियादी अंडरलाइनिंग मिलेगी, लेकिन कोई भी ऑटो-पूरी सूची या टूलटिप्स और सभी मज़ेदार सामान नहीं। मैंने इस मुद्दे के बारे में एक बग दर्ज किया, और यह खुला रहता है - और एक और जो इस कदम से बच नहीं पाया।

---

SQL सर्वर डेटा उपकरण

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

---

परिवर्तन करें

ALTER DATABASEकिसी समाहित डेटाबेस के संदर्भ में एक कमांड चलाने के दौरान, ALTER DATABASE fooआप की तुलना में rRather का उपयोग करने की आवश्यकता होगी ALTER DATABASE CURRENT- यह इतना है कि यदि डेटाबेस को स्थानांतरित, नाम बदला गया है, आदि, इन आदेशों को उनके बाहरी संदर्भ या संदर्भ के बारे में कुछ भी जानने की आवश्यकता नहीं है ।

---

कुछ अन्य

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

• गिने जाने की प्रक्रिया
• अस्थायी प्रक्रिया
• बंधी हुई वस्तुओं में टकराव बदल जाता है
• डेटा कैप्चर बदलें
• ट्रैकिंग बदलें
• प्रतिकृति

---

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

आपको यह भी सुनिश्चित करना होगा कि यदि कोई निहित डेटाबेस माइग्रेट होने जा रहा है, या उपलब्धता समूह का हिस्सा है या मिरर किया जा रहा है, तो सभी संभावित गंतव्य सर्वरों में sp_configureविकल्प contained database authentication1 पर सेट है।

आपको यह ब्लॉग पोस्ट उपयोगी लग सकता है, साथ ही साथ यह एक है , भले ही वे आरटीएम पूर्व-तिथि हो।

Comments

क्या आप जानते हैं कि अस्थायी प्रक्रियाओं की अनुमति क्यों नहीं है?

— जॉन सीगल

@JonSeigel उन्हें अभी भी आंशिक प्रतिबंध के तहत अनुमति दी गई है, लेकिन वे उल्लंघन को रोकते हैं (इसका अर्थ यह है कि प्रक्रिया को एक्सेस करने वाली संस्थाओं को मान्य करने का कोई तरीका नहीं है, क्योंकि यह मेटाडेटा और परिभाषा कहीं और संग्रहीत है) इसलिए अनुशंसित नहीं हैं। से msdn.microsoft.com/en-us/library/ff929071.aspx#Limitations : अस्थायी संग्रहित प्रक्रियाओं वर्तमान की अनुमति है। क्योंकि अस्थायी संग्रहीत कार्यविधियाँ नियंत्रण को भंग कर देती हैं, वे निहित डेटाबेस के भविष्य के संस्करणों में समर्थित होने की उम्मीद नहीं करते हैं।

— हारून बर्ट्रेंड

Answer 2

जो लोग निहित डेटाबेस के बारे में अधिक जानकारी प्राप्त करने में रुचि रखते हैं, मैं उन्हें इस लेख को पढ़ने के लिए सलाह दे सकता हूं http://www.sqlshack.com/contain-dat डेटाबेस-in- sql- server /

लेख में निहित डेटाबेस का उपयोग करने के मुख्य फायदे / नुकसान हैं।

नुकसान

आंशिक रूप से सम्‍मिलित डेटाबेस प्रतिकृति, डेटा परिवर्तन, परिवर्तन ट्रैकिंग, स्कीमा-बाउंड ऑब्जेक्ट जैसी सुविधाओं का उपयोग नहीं कर सकते हैं जो अंतर्निहित परिवर्तनों के साथ अंतर्निहित कार्यों पर निर्भर करते हैं।

लाभ

दूसरी ओर, जैसा कि पहले ही उल्लेख किया गया है, निहित डीबी का उपयोग करने के कुछ लाभ हैं, जैसे:

• डेटाबेस को एक सर्वर से दूसरे सर्वर पर ले जाना काफी आसान है,
  क्योंकि इसमें यूजर अनाथ नहीं होंगे
• मेटाडेटा निहित डेटाबेस पर संग्रहीत किया जाता है, इसलिए यह आसान और अधिक पोर्टेबल है
• निहित DB उपयोगकर्ताओं के लिए SQL सर्वर और Windows प्रमाणीकरण दोनों होना संभव है

अनुच्छेद भी इसके साथ मदद करता है:

• एक नया निहित डेटाबेस बनाना (SQL सर्वर में विकल्प पृष्ठ में आंशिक के रूप में रोकथाम प्रकार बनाकर, और बाद में डेटाबेस बनाने के लिए T-SQL क्वेरी का उपयोग करके)
• SQL सर्वर प्रबंधन स्टूडियो का उपयोग करके निहित DB से कनेक्ट करना (कनेक्शन पैरामीटर में निहित DB नाम निर्दिष्ट करना आवश्यक है)
• मौजूदा डेटाबेस को एक निहित डेटाबेस में परिवर्तित करना
• एक निहित डेटाबेस पर काम करना और सभी लॉगिन को सूचीबद्ध करना जो निहित उपयोगकर्ता प्रकार के हैं

Answer 3

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

अतिरिक्त नोट यह है कि, मुझे "PIVOT" और "UNPIVOT" खंड में अप्रत्याशित और अनिर्धारित मेटाडेटा उपयोग मिला, जो मुझे लगा कि यह केवल सिस्टम कैटलॉग में ही होना चाहिए (sys.tables / sys.columns / etc)। Msdn में प्रलेखित :

एक समाहित डेटाबेस में, कैटलॉग लैटिन 1_General_100_CI_AS_WS_KS_SC टकराता है । यह टकराव SQL सर्वर के सभी इंस्टेंस पर सभी निहित डेटाबेस के लिए समान है और इसे बदला नहीं जा सकता है।

लेकिन उन्होंने उल्लेख नहीं किया कि "PIVOT" और "UNIVIVOT" क्लॉज भी सिस्टम कैटलॉग को निष्पादन तंत्र के रूप में उपयोग करते हैं। इसलिए यह प्रवास के दौरान "PIVOT" और "UNPIVOT" क्लॉज के उपयोग के आसपास हर जगह एक टकराव वाली त्रुटि उत्पन्न करता है। यहाँ कुछ repro है:

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

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