Ok, mari kita jabarkan:
- Bagaimana gabungan dibangun antara dua tabel pada banyak basis data? (Contoh kode di sini akan sangat membantu).
Ini sangat mudah. Objek SQL memiliki konvensi penamaan satu hingga empat bagian:
Servername.databasename.schemaname.tablename
Jika semua tabel Anda berada di server yang sama pada database yang sama, dengan pemilik / skema yang sama, Anda bisa mengabaikan tiga bagian pertama dan menggunakan apa yang paling sering Anda gunakan untuk:
Select a.*,b.* from
tableA a inner join
tableB b on a.col1=b.col1
Jika salah satu tabel Anda berada di database yang berbeda dan keduanya menggunakan skema default untuk database mereka, maka Anda cukup menambahkan database ke tabel kedua:
Select a.*,b.* from
tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Jika Anda berada di basis data ketiga yang berbeda dari yang Anda tanyakan, Anda menggunakan kedua nama basis data secara eksplisit:
Select a.*,b.* from
databaseD..tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Jika Anda akhirnya menggunakan skema dan / atau pemilik yang berbeda, Anda dapat menambahkannya di:
Select a.*,b.* from
databaseD.john.tableA a inner join
databaseC.accounting.tableB b on a.col1 = b.col1
Dan terakhir, jika Anda sangat berhati-hati tentang hal itu dan memiliki alasan yang sangat baik, Anda dapat bergabung dengan tabel (biasanya kecil) di server lain:
Select a.* from
databaseD.john.TableA a inner join
ATLANTA.databaseC.accounting.tableB b on a.col1 = b.col1
- Kapan waktu untuk bergerak melampaui pengaturan 1 database / 1 server? Seberapa umum perlu melakukan ini? Apakah ada strategi khusus untuk melacak tabel mana di basis data mana?
Saya akan menggabungkan keduanya karena mereka pergi bersama. Anda hampir selalu umumnya baik-baik saja untuk memulai dengan asumsi bahwa satu database satu server sudah cukup sampai kendala desain / bisnis / teknis Anda memaksa Anda untuk menggunakan lebih banyak.
Jadi, untuk menjawab pertanyaan kedua Anda terlebih dahulu, karena Anda umumnya memiliki alasan untuk memiliki basis data yang terpisah, itu harus cukup jelas dari mengetahui desain sistem Anda di mana ada sesuatu.
Seperti kapan / mengapa itu perlu untuk bergerak melampaui satu basis data tunggal. Biasanya itu campuran aturan bisnis, politik, dan / atau alasan teknis.
Misalnya, tempat saya bekerja, kami memiliki 16 basis data yang tersebar di 4 server. Kami memiliki MainDB, ImageDB, referencetableDB, HighvolumeTransactionDB, ReportingDB, StagingDB, ProcessingDB, ArchiveDB, FinancialDB. Untuk memberikan beberapa contoh mengapa mereka berbeda:
- FinancialDB, informasi sensitif
- Image DB, persyaratan penyimpanan dan pemulihan berbeda yang spesifik
- ReferenceDB, transaksi rendah, baca tinggi
- ReportingDB, baca sangat tinggi, perlu dipulihkan / direplikasi ke berbagai lingkungan lain tidak seperti banyak data lainnya
- StagingDB, tidak ada yang permanen, hanya tempdb yang lebih besar yang kita punya lebih banyak kontrol
- MainDB, antarmuka dengan semua DB lain tetapi membutuhkan cadangan diferensial jadi ... kami membagi
- Tabel HighVolumeTransaction, (yang relatif sementara), ke DB mereka sendiri untuk menjaga ukuran wajar cadangan.
- Arsip, Banyak data yang sama dari Utama dan Pelaporan, tetapi dengan periode retensi yang lebih lama dan kueri yang lebih keras, menggali lebih dalam data. Jika ini masih dikombinasikan dengan Utama / Pelaporan itu akan merusak sistem kami.
• Apakah kode aplikasi perlu tahu bahwa satu atau lebih database tersebar di beberapa server? Jika tidak, pada tingkat apa permintaan difilter?
Dalam arti luas, mereka mungkin melakukannya. Minimal mereka perlu tahu server apa yang mereka tunjuk dalam string koneksi database. Memproses, Melaporkan, Utama, dll.
Dari sana, mereka membutuhkan konteks basis data untuk dieksekusi di bawah. Secara umum itu akan menjadi yang paling banyak digunakan untuk aplikasi, bahkan mungkin yang asli dari satu database / satu hari server aplikasi. Anda BISA memiliki aplikasi secara eksplisit beralih konteks database pada setiap panggilan tetapi itu membuatnya sangat sulit untuk menyesuaikan database tanpa mengubah aplikasi.
Pendekatan yang biasa, (atau paling tidak, SAYA biasa), adalah untuk selalu mengakses melalui satu atau mungkin dua basis data utama.
Kemudian buat tampilan ke database lain yang diperlukan dikombinasikan dengan interfacing dengan database melalui prosedur yang tersimpan.
Jadi untuk menggambarkan:
Katakanlah Anda ingin mendapatkan informasi demografis, data penjualan, dan saldo Kredit Klien dan yang tersebar di tiga tabel pada awalnya semuanya di MainDB.
Jadi Anda menulis panggilan dari aplikasi Anda:
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
Luar biasa. Namun, sekarang kapan pun kami mengubah nama kolom, atau mengganti nama / memindahkan tabel, Anda harus memperbarui kode aplikasi. Jadi alih-alih, kami melakukan dua hal:
Buat Klien, Penjualan, Tampilan Akun yang Dapat Diterima (Anda tidak akan menggunakan Pilih * tetapi saya sedang melakukan demo di sini)
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
Lalu kami juga akan membuat prosedur tersimpan, 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
Dan mintalah panggilan aplikasi Anda itu.
Sekarang selama saya tidak mengubah antarmuka pada proc yang disimpan itu, saya bisa melakukan apa saja yang perlu saya lakukan pada database backend untuk memperbesar atau memperkecil.
Secara ekstrem, saya bahkan bisa membuat MainDB lama saya hanya sekelompok prosedur dan pandangan tersimpan yang tersimpan sehingga di bawah pandangan yang kami buat tampak seperti ini:
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
Dan aplikasi Anda tidak akan pernah tahu bedanya, (dengan asumsi pipa cepat dan data yang dipentaskan dengan baik antara lain).
Jelas itu ekstrem dan saya akan berbohong jika saya mengatakan semuanya sudah direncanakan dengan cara ini, tetapi menggunakan prosedur / tampilan yang tersimpan bahkan jika Anda melakukannya saat refactoring akan memungkinkan Anda banyak fleksibilitas ketika aplikasi Anda tumbuh dari satu database / satu server yang sederhana awal.