ठीक है, चलो इसे तोड़ दो:
- कई डेटाबेस पर दो तालिकाओं के बीच कैसे जुड़ते हैं? (यहां एक कोड उदाहरण उपयोगी होगा)।
यह बहुत सीधा है। SQL ऑब्जेक्ट्स में एक से चार भाग के नामकरण सम्मेलन कहीं भी होते हैं:
Servername.databasename.schemaname.tablename
यदि आपके सभी टेबल एक ही डेटाबेस पर एक ही सर्वर पर हैं, एक ही मालिक / स्कीमा के साथ, आप पहले तीन भागों को अनदेखा कर सकते हैं और वे उपयोग कर सकते हैं जो आपके लिए सबसे अधिक उपयोग किए जाते हैं:
Select a.*,b.* from
tableA a inner join
tableB b on a.col1=b.col1
यदि आपकी कोई तालिका किसी भिन्न डेटाबेस में है और दोनों अपने डेटाबेस के लिए डिफ़ॉल्ट स्कीमा का उपयोग करते हैं, तो आप बस डेटाबेस को दूसरी तालिका में जोड़ते हैं:
Select a.*,b.* from
tableA a inner join
databaseC..tableB b on a.col1 = b.col1
यदि आप किसी तीसरे डेटाबेस में हैं, तो आप उन दोनों डेटाबेस नामों से अलग हैं, जिनका आप स्पष्ट रूप से उपयोग कर रहे हैं:
Select a.*,b.* from
databaseD..tableA a inner join
databaseC..tableB b on a.col1 = b.col1
यदि आप अलग-अलग स्कीमा और / या मालिकों का उपयोग करके समाप्त होते हैं, तो आप उन्हें इसमें जोड़ सकते हैं:
Select a.*,b.* from
databaseD.john.tableA a inner join
databaseC.accounting.tableB b on a.col1 = b.col1
और अंत में, यदि आप इसके बारे में बहुत सावधान हैं और एक बहुत अच्छा कारण है, तो आप किसी अन्य सर्वर पर एक (आमतौर पर छोटी) तालिका में शामिल हो सकते हैं:
Select a.* from
databaseD.john.TableA a inner join
ATLANTA.databaseC.accounting.tableB b on a.col1 = b.col1
- 1 डेटाबेस / 1 सर्वर सेटअप से आगे बढ़ने का समय कब है? ऐसा करना कितना आम है? क्या ट्रैकिंग के लिए कोई विशेष रणनीति है कि कौन सी तालिकाएँ डेटाबेस में हैं?
मैं इन दोनों को मिला दूंगा क्योंकि वे एक साथ चलते हैं। आप लगभग हमेशा आम तौर पर इस धारणा के साथ शुरू करने के लिए ठीक हैं कि एक डेटाबेस एक सर्वर पर्याप्त है जब तक कि आपका डिज़ाइन / व्यवसाय / तकनीकी बाधा आपको अधिक उपयोग करने के लिए मजबूर न करें।
इसलिए पहले अपने दूसरे प्रश्न का उत्तर देने के लिए, क्योंकि आपके पास आम तौर पर अलग-अलग डेटाबेस होने का एक कारण है, यह आपके सिस्टम के डिजाइन को जानने से काफी स्पष्ट होना चाहिए जहां कुछ है।
एक डेटाबेस से आगे बढ़ने के लिए कब / क्यों आवश्यक है। आमतौर पर यह व्यावसायिक नियमों, राजनीति और / या तकनीकी कारणों का मिश्रण है।
उदाहरण के लिए, जहां मैं काम करता हूं हमारे पास 4 सर्वरों में फैले 16 डेटाबेस हैं। हमारे पास एक MainDB, ImageDB, referencetableDB, HighvolumeTransactionDB, ReportingDB, StagingDB, ProcessingDB, ArchiveDB, FinancialDB है। वे अलग क्यों हैं के कुछ उदाहरण देने के लिए:
- FinancialDB, संवेदनशील जानकारी
- छवि DB, विशिष्ट अलग भंडारण और पुनर्प्राप्ति आवश्यकताओं
- ReferenceDB, कम लेनदेन, उच्च पढ़ें
- रिपोर्टिंग डेटा, बहुत अधिक पढ़ी गई, बहुत से अन्य डेटा के विपरीत विभिन्न अन्य वातावरणों को पुनर्स्थापित / प्रतिकृति करने की आवश्यकता है
- StagingDB, कुछ भी स्थायी नहीं है, बस एक अस्थायी अस्थायी है जो हमारे पास अधिक नियंत्रण है
- MainDB, अन्य सभी DB के साथ इंटरफेस है, लेकिन अंतर बैकअप की जरूरत है ... हम बाहर विभाजित
- HighVolumeTransaction तालिकाओं, (जो अपेक्षाकृत क्षणिक हैं), अपने स्वयं के DB तक ताकि बैकअप उचित आकार रखने के लिए।
- पुरालेख, मुख्य और रिपोर्टिंग से एक ही डेटा के बहुत सारे, लेकिन लंबे समय तक अवधारण अवधि और कठिन मार सवालों के साथ डेटा में गहरी खुदाई। यदि यह अभी भी Main / Reporting के साथ संयुक्त था, तो यह हमारे सिस्टम को नीचे गिरा देगा।
• क्या एप्लिकेशन कोड को यह जानने की जरूरत है कि एक या अधिक डेटाबेस कई सर्वरों में फैले हुए हैं? यदि नहीं, तो किस स्तर पर अनुरोध फ़िल्टर किए जाते हैं?
एक व्यापक अर्थ में, वे शायद करते हैं। कम से कम उन्हें यह जानने की जरूरत है कि वे डेटाबेस कनेक्शन स्ट्रिंग में किस सर्वर की ओर इशारा कर रहे हैं। प्रसंस्करण, रिपोर्टिंग, मुख्य, आदि।
वहां से, उन्हें निष्पादित करने के लिए एक डेटाबेस संदर्भ की आवश्यकता होती है। आम तौर पर यह अनुप्रयोग के लिए सबसे अधिक इस्तेमाल किया जाने वाला एक होगा, हो सकता है कि आवेदन के एक डेटाबेस / एक सर्वर दिनों से मूल एक भी हो। आपके पास हर कॉल पर स्पष्ट रूप से डेटाबेस संदर्भ स्विच हो सकता है लेकिन इससे ऐप को बदले बिना डेटाबेस को समायोजित करना बहुत कठिन हो जाता है।
सामान्य, (या कम से कम, MY सामान्य), दृष्टिकोण हमेशा एक या शायद दो मुख्य डेटाबेस के माध्यम से उपयोग करना है।
फिर संग्रहीत प्रक्रियाओं के माध्यम से डेटाबेस के साथ इंटरफेस करने के लिए आवश्यक के रूप में अन्य डेटाबेस में विचार बनाएं।
इसलिए वर्णन करने के लिए:
मान लें कि आप एक ग्राहक की जनसांख्यिकीय जानकारी, बिक्री डेटा और क्रेडिट शेष प्राप्त करना चाहते हैं और यह मुख्य रूप से सभी तीन तालिकाओं में फैली हुई है जो कि मुख्य रूप से सभी मेनबीडी में हैं।
तो आप अपने ऐप से कॉल लिखें:
Select c.ClientName, c.ClientAddress, s.totalSales,f.CreditBlance from
Clients c join Sales s on c.clientid = s.clientid inner join AccountReceivable f on
c.clientid=f.clientid where c.clientid = @clientid
बहुत बढ़िया। हालाँकि, अब किसी भी समय हम एक कॉलुमनाम बदल देते हैं, या किसी तालिका का नाम बदल / स्थानांतरित कर देते हैं, आपको ऐप कोड अपडेट करना होगा। इसलिए इसके बजाय हम दो काम करते हैं:
ग्राहक बनाएँ, बिक्री, खातासंग्रह दृश्य (आप चयन का उपयोग नहीं करेंगे * लेकिन मैं यहां प्रदर्शन कर रहा हूं)
Use MainDB
GO
Create view v_Clients as select * from Clients
Create view v_Sales as select * from Sales
Create view v_AccountReceivable as select * from AccountReceivable
Go
तो फिर हम एक संग्रहीत प्रक्रिया, spGetClientSalesAR भी बनाएंगे
Create proc spGetClientSalesAR @clientID int
as
Select c.ClientName as ClientName,
c.ClientAddress as ClientAddress,
s.totalSales as TotalSales,
f.CreditBlance as CreditBalance
from
v_Clients c join v_Sales s
on c.clientid = s.clientid
inner join v_AccountReceivable f
on c.clientid=f.clientid
where c.clientid = @clientid
और अपने ऐप को कॉल करें।
अब जब तक मैं उस संग्रहित खरीद पर इंटरफ़ेस को नहीं बदलता, मैं बहुत कुछ कर सकता हूं जो मुझे बैकेंड डेटाबेस में ऊपर या बाहर पैमाने पर करने की आवश्यकता है।
चरम में, मैं अपने पुराने मेनडीबी को केवल शेल किए गए संग्रहीत प्रक्रियाओं का एक गुच्छा बना सकता था और इस तरह के विचार जो हमने बनाए उन विचारों के नीचे थे:
Create view v_Clients as select * from ServerX.DatabaseY.dbo.Clients
Create view v_Sales as select * from ServerQ.DatabaseP.dbo.Sales
Create view v_AccountReceivable as select * from ServerJ.DatabaseK.dbo.AccountReceivable
और आपके ऐप को कभी भी अंतर नहीं पता होगा, (तेजी से पाइप और अन्य चीजों के बीच अच्छी तरह से डेटा का अनुमान लगाते हुए)।
जाहिर है कि यह चरम है और मैं झूठ बोल रहा हूं अगर मैंने कहा कि सब कुछ इस तरह से योजनाबद्ध था, लेकिन संग्रहीत प्रक्रियाओं / विचारों का उपयोग करते हुए भले ही आप इसे करते हैं, फिर से काम करते समय आपको बहुत लचीलापन मिलेगा क्योंकि आपका ऐप अपने विनम्र एक डेटाबेस / एक सर्वर से बढ़ता है। इसकी शुरुआत हुई।