Po pierwsze, pod względem architektonicznym, byłbym dość nieufny wobec każdego projektu, który wymagałby przeciągania danych przez wiele łączy bazy danych. Widziałem, jak to się robi, gdy ostatecznym źródłem jest jakaś starożytna wersja Oracle, z którą docelowa baza danych nie może połączyć się bezpośrednio, więc użyto pośredniej bazy danych z pośrednią wersją Oracle. W praktyce jest to jednak bardzo rzadkie.
Z perspektywy performansu takie podejście jest bardzo problematyczne. Pojawia się oczywiście problem, że dane będą przesyłane przez sieć dwukrotnie. Ale co bardziej niepokojące, podejmujesz trudny problem, optymalizując rozproszone instrukcje SQL i czyniąc go prawie niewykonalnym. Zasadniczo musiałbyś albo zagwarantować, że nigdy nie wykonasz zapytań dotyczących danych lokalnych i zdalnych w tym samym zapytaniu, albo będziesz musiał żyć z wynikową wydajnością, jeśli Oracle zdecyduje się na głupi plan zapytań, ponieważ zestaw narzędzi pozostawiony, aby umożliwić ci optymalizacja tego rodzaju zapytania jest minimalna.
Biorąc to pod uwagę, pośrednia baza danych musiałaby mieć synonimy lub widoki, które abstrahują od łącza bazy danych. Więc
Na A:
- utwórz łącze bazy danych do B
Na B:
- utwórz łącze bazy danych do C
- utwórz synonim
tabledla[email protected]
Na A możesz wtedy
SELECT *
FROM [email protected]
