Ok, podzielmy to:
- Jak budowane są sprzężenia między dwiema tabelami w wielu bazach danych? (Przydałby się tutaj przykładowy kod).
To całkiem proste. Obiekty SQL mają dowolną konwencję nazewnictwa od jednej do czterech części:
Servername.databasename.schemaname.tablename
Jeśli wszystkie tabele znajdują się na tym samym serwerze w tej samej bazie danych, z tym samym właścicielem / schematem, możesz po prostu zignorować pierwsze trzy części i użyć tego, do czego najczęściej jesteś przyzwyczajony:
Select a.*,b.* from
tableA a inner join
tableB b on a.col1=b.col1
Jeśli jedna z tabel znajduje się w innej bazie danych i obie używają domyślnego schematu dla swoich baz danych, po prostu dodajesz bazę danych do drugiej tabeli:
Select a.*,b.* from
tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Jeśli akurat znajdujesz się w trzeciej bazie danych innej niż ta, której dotyczy zapytanie, jawnie użyj obu nazw baz danych:
Select a.*,b.* from
databaseD..tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Jeśli w końcu użyjesz różnych schematów i / lub właścicieli, możesz dodać je w:
Select a.*,b.* from
databaseD.john.tableA a inner join
databaseC.accounting.tableB b on a.col1 = b.col1
I na koniec, jeśli jesteś bardzo ostrożny i masz bardzo dobry powód, możesz dołączyć do (zwykle małej) tabeli na innym serwerze:
Select a.* from
databaseD.john.TableA a inner join
ATLANTA.databaseC.accounting.tableB b on a.col1 = b.col1
- Kiedy należy wyjść poza konfigurację 1 bazy danych / 1 serwera? Jak często trzeba to robić? Czy są jakieś specjalne strategie śledzenia, które tabele znajdują się w której bazie danych?
Połączę te dwa, ponieważ idą w parze. Prawie zawsze dobrze jest zacząć od założenia, że jedna baza danych wystarcza na jeden serwer, dopóki ograniczenia projektowe / biznesowe / techniczne nie zmuszą Cię do korzystania z większej ilości.
Aby więc najpierw odpowiedzieć na drugie pytanie, ponieważ generalnie masz powód posiadania oddzielnych baz danych, powinno to być dość oczywiste ze znajomości projektu systemu, w którym coś jest.
Co do tego, kiedy / dlaczego konieczne jest przejście poza jedną bazę danych. Zwykle jest to mieszanka reguł biznesowych, polityki i / lub powodów technicznych.
Na przykład tam, gdzie pracuję, mamy 16 baz danych rozproszonych na 4 serwerach. Mamy MainDB, ImageDB, referencetableDB, HighvolumeTransactionDB, ReportingDB, StagingDB, ProcessingDB, ArchiveDB, FinancialDB. Aby podać przykłady, dlaczego się różnią:
- FinancialDB, informacje wrażliwe
- Baza danych obrazów, określone różne wymagania dotyczące przechowywania i odzyskiwania
- ReferenceDB, niska transakcja, wysoki odczyt
- ReportingDB, bardzo wysoki odczyt, musi zostać przywrócony / zreplikowany w różnych innych środowiskach, w przeciwieństwie do wielu innych danych
- StagingDB, nic stałego, tylko rozbudowana tempdb, nad którą mamy większą kontrolę
- MainDB, interfejsy z wszystkimi innymi bazami danych, ale wymaga różnicowych kopii zapasowych, więc ... rozdzieliliśmy
- Tabele HighVolumeTransaction (które są stosunkowo przejściowe) do ich własnej bazy danych, aby zachować rozsądny rozmiar kopii zapasowej.
- Archiwum, wiele takich samych danych z Main i Reporting, ale z dłuższymi okresami przechowywania i trudniejszymi zapytaniami sięgającymi głęboko w dane. Gdyby to było nadal połączone z Main / Reporting, spowodowałoby to zapadnięcie się naszego systemu.
• Czy kod aplikacji musi wiedzieć, że jedna lub więcej baz danych jest rozproszonych na wielu serwerach? Jeśli nie, na jakim poziomie żądania są filtrowane?
W szerokim sensie prawdopodobnie tak. Muszą przynajmniej wiedzieć, na jaki serwer wskazują w ciągu połączenia z bazą danych. Przetwarzanie, raportowanie, główne itp.
Stamtąd potrzebują kontekstu bazy danych, aby wykonać. Zasadniczo byłby to najczęściej używany w aplikacji, być może nawet oryginalny z jednej bazy danych / jednego serwera dni aplikacji. MOŻESZ mieć aplikację wyraźnie przełączającą kontekst bazy danych przy każdym wywołaniu, ale bardzo utrudnia to dostosowanie bazy danych bez zmiany aplikacji.
Zwykle (a przynajmniej MY zwykle) podejście polega na tym, aby zawsze uzyskiwać dostęp za pośrednictwem jednej lub dwóch głównych baz danych.
Następnie w razie potrzeby utwórz widoki do innych baz danych w połączeniu z łączeniem się z bazą danych za pomocą procedur przechowywanych.
Aby zilustrować:
Załóżmy, że chcesz uzyskać informacje demograficzne klienta, dane sprzedaży i saldo kredytu, które są rozłożone na trzy tabele pierwotnie wszystkie w MainDB.
Więc piszesz połączenie ze swojej aplikacji:
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
Niesamowite. Jednak teraz za każdym razem, gdy zmieniamy nazwę kolumny lub zmieniamy nazwę / przenosimy tabelę, musisz zaktualizować kod aplikacji. Zamiast tego robimy dwie rzeczy:
Tworzymy klientów, Sprzedaż, Widoki Konta Odbiorcy (nie używałbyś Select *, ale tutaj demonstruję)
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
Następnie utworzylibyśmy również procedurę przechowywaną, 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
I niech twoja aplikacja to nazwie.
Teraz, dopóki nie zmieniam interfejsu w tym przechowywanym proc, mogę praktycznie zrobić wszystko, co muszę zrobić z bazą danych zaplecza, aby zwiększyć lub zmniejszyć.
W skrajności mógłbym nawet uczynić mój stary MainDB tylko zbiorem procedur przechowywanych w skorupie i widokami, tak że pod tymi widokami, które stworzyliśmy, wyglądało to tak:
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
A Twoja aplikacja nigdy nie pozna różnicy (zakładając między innymi szybkie rury i dobrze zainscenizowane dane).
Oczywiście to ekstremalne i kłamałbym, gdybym powiedział, że wszystko zostało zaplanowane w ten sposób, ale korzystanie z procedur / widoków przechowywanych, nawet jeśli robisz to podczas refaktoryzacji, zapewni ci dużą elastyczność, gdy Twoja aplikacja wyrasta ze skromnej bazy danych / jednego serwera początek.