Tamam, yıkalım:
- Birden çok veritabanındaki iki tablo arasında birleştirmeler nasıl oluşturulur? (Burada bir kod örneği yardımcı olacaktır).
Bu oldukça basit. SQL Nesneleri, bir ila dört bölüm adlandırma kuralına sahiptir:
Servername.databasename.schemaname.tablename
Tüm tablolarınız aynı veritabanında, aynı sahip / şema ile aynı sunucudaysa, ilk üç bölümü yok sayabilir ve en çok kullandığınız şeyi kullanabilirsiniz:
Select a.*,b.* from
tableA a inner join
tableB b on a.col1=b.col1
Tablolarınızdan biri farklı bir veritabanındaysa ve her ikisi de veritabanları için varsayılan şemayı kullanıyorsa, veritabanını ikinci tabloya eklemeniz yeterlidir:
Select a.*,b.* from
tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Sorguladığınız veritabanlarından farklı bir üçüncü veritabanındaysanız, her iki veritabanı adını da açıkça kullanırsınız:
Select a.*,b.* from
databaseD..tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Sonunda farklı şemalar ve / veya sahipler kullanırsanız, bunları şuralara ekleyebilirsiniz:
Select a.*,b.* from
databaseD.john.tableA a inner join
databaseC.accounting.tableB b on a.col1 = b.col1
Ve son olarak, bu konuda çok dikkatli iseniz ve çok iyi bir nedeniniz varsa, başka bir sunucuda (genellikle küçük) bir masaya katılabilirsiniz:
Select a.* from
databaseD.john.TableA a inner join
ATLANTA.databaseC.accounting.tableB b on a.col1 = b.col1
- 1 veritabanı / 1 sunucu kurulumunun ötesine geçme zamanı ne zaman? Bunu yapmak ne kadar yaygındır? Hangi veritabanında hangi tabloların bulunduğunu izlemek için özel stratejiler var mı?
Bu ikisini birleştireceğim çünkü birlikte gidiyorlar. Tasarım / iş / teknik kısıtlamalarınız sizi daha fazla kullanmaya zorlayana kadar, bir veritabanının bir sunucunun yeterli olduğu varsayımıyla başlamak için neredeyse her zaman iyisinizdir.
Bu nedenle, önce ikinci sorunuzu cevaplamak için, genellikle ayrı veritabanlarına sahip olmanız için bir nedeniniz olduğundan, sisteminizin tasarımının bir şeyin nerede olduğunu bilmesinden oldukça açık olması gerekir.
Ne zaman / neden tek bir veritabanının ötesine geçmek gerektiğine gelince. Genellikle iş kuralları, politika ve / veya teknik nedenlerin bir karışımıdır.
Örneğin, çalıştığım yerde 4 sunucuya yayılmış 16 veritabanımız var. Bir MainDB, ImageDB, referencetableDB, HighvolumeTransactionDB, ReportingDB, StagingDB, ProcessingDB, ArchiveDB, FinancialDB var. Neden farklı olduklarına dair bazı örnekler vermek için:
- FinancialDB, hassas bilgiler
- Image DB, belirli farklı depolama ve kurtarma gereksinimleri
- ReferenceDB, düşük işlem, yüksek okuma
- RaporlamaDB, çok yüksek okuma, diğer verilerin çoğunun aksine, diğer çeşitli ortamlara geri yüklenmesi / çoğaltılması gerekiyor
- StagingDB, kalıcı bir şey değil, sadece üzerinde daha fazla kontrole sahip olduğumuz bir sığır tempdb
- MainDB, diğer tüm DB'lerle arayüz oluşturur, ancak diferansiyel yedeklemeye ihtiyaç duyar, bu yüzden ...
- HighVolumeTransaction tabloları (nispeten geçici olan), yedeklemenin makul büyüklüğünü korumak için kendi DB'lerine.
- Arşiv, Ana ve Raporlama ile aynı verilerin birçoğu, ancak daha uzun saklama süreleri ve verilerin derinlemesine kazılması daha zor isabet sorguları ile. Bu hala Ana / Raporlama ile birleştirilse, sistemimizi batar.
• Uygulama kodunun bir veya daha fazla veritabanının birden çok sunucuya yayıldığını bilmesi gerekiyor mu? Değilse, talepler hangi düzeyde filtrelenir?
Geniş anlamda, muhtemelen yaparlar. En azından veritabanı bağlantı dizesinde hangi sunucuyu işaret ettiklerini bilmeleri gerekir. İşleme, Raporlama, Ana vb.
Oradan altında çalıştırmak için bir veritabanı bağlamına ihtiyaç duyarlar. Genellikle bu uygulama için en çok kullanılan, hatta bir veritabanı / uygulamanın bir sunucu gün orijinal olabilir. Uygulamanın her çağrıda açıkça veritabanı bağlamını değiştirmesini sağlayabilirsiniz, ancak bu, uygulamayı değiştirmeden veritabanını ayarlamayı zorlaştırır.
Her zamanki (ya da en azından benim olağan) yaklaşım, her zaman bir ya da belki iki ana veritabanından erişmektir.
Ardından, saklı yordamlar aracılığıyla veritabanıyla arabirim oluşturmakla birlikte gerektiğinde diğer veritabanlarına görünümler oluşturun.
Açıklamak gerekirse:
Diyelim ki bir Müşterinin demografik bilgilerini, Satış verilerini ve Kredi bakiyesini almak istiyorsunuz ve bu aslında tüm MainDB'de üç tabloya yayılmıştır.
Yani uygulamanızdan bir çağrı yazıyorsunuz:
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
Muhteşem. Ancak, şimdi bir sütun adını değiştirdiğimizde veya bir tabloyu yeniden adlandırdığımızda / taşıdığımızda uygulama kodunu güncellemeniz gerekir. Bunun yerine iki şey yapıyoruz:
İstemciler, Satışlar, Hesap Alımları Görünümleri Oluştur (Select * kullanmazsınız, ancak burada demo yapıyorum)
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
Sonra bir de saklı yordam, spGetClientSalesAR oluşturmak
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
Ve uygulamanızın bunu aramasını sağlayın.
Şimdi o saklı proc arabirimi değiştirmek sürece, ben hemen hemen ölçeklendirmek veya dışarı arka uç veritabanına yapmak için gereken her şeyi yapabilirim.
Aşırı olarak, eski MainDB'mi bile oluşturduğumuz bu görünümlerin altında şöyle görünüyordu:
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
Ve uygulamanız farkı asla bilemez, (diğer şeylerin yanı sıra hızlı borular ve iyi hazırlanmış veriler varsayarak).
Açıkçası bu aşırı ve her şeyin bu şekilde planlandığını söylesem yalan söylüyordum, ancak yeniden düzenleme sırasında yapsanız bile saklı yordamları / görünümleri kullanmak, uygulamanız mütevazi bir veritabanından / bir sunucusundan büyüdükçe size çok fazla esneklik sağlayacaktır. başlangıç.