Czy istnieje możliwość wykonania joina na tabelach dwóch baz, znajdujących się na dwóch RÓŻNYCH serwerach?
0
0
Nie, ale można probować wykonać takie coś jak replikacja jednej z tabel do drugiej bazy i dopiero wtedy JOIN.
ps. Jednak muszę zadać to pytanie po co tak kombinować?
0
W MySQLu tak jak napisał Koziołek. Natomiast w DB2 nie ma najmniejszego problemu. Żeby robić takie rzeczy musisz mieć system obsługujący rozproszone bazy danych. Poczekamy 20 lat, może w MySQL też będzie.
0
Zastanawiam sie czy nie można tutaj wykorzystac widokow?
Jesli mozna stworzyc widok z dazy danych innego serwera to mozna za jego posrednictwem wykonac JOINa.
Jedyne co mi przychodzi do głowy to wykorzystanie Domeny Windows Server, oraz Microsoft SQL Server i skonfigurowac tak bazy danych aby zawsze dazyły do stanu konwergencji wtedy problem znika.
Ewentualnie napisac program ktory pobierze dane z obu serwerow np w postaci XML, a potem je odpowiednio obrobi.
0
Koziołek napisał(a)
Nie, ale można probować wykonać takie coś jak replikacja jednej z tabel do drugiej bazy i dopiero wtedy JOIN.
hmmm..... niegłupie z tą replikacją, ale narzut powoduje straszny :-(
Koziołek napisał(a)
ps. Jednak muszę zadać to pytanie po co tak kombinować?
na potrzeby swego serwisu podejmuję próby integracji joomli z przemo. i chcę mieć osobną bazę dla przema i osobną dla joomli, a ponieważ mój hosting każdej bazie przyznaje inny serwer to mam zonka.
chyba jedynym sposobem jest w takim razie programowy "pseudo-join" na danych w pamięci, już pobranych z bazy, co jednak wydaje się jeszcze bardziej topornym rozwiązaniem.
0
a to nie rób tak. Skoro już mamy szerszy kontekst problemu to jest łatwiejsza metoda. Ręcznie zainstaluj bazę przemo i joomli w ramach JEDNEJ bazy danych. Jest to możliwe, bo zarówno joomla jak i przemo, jeżeli dobrze pamiętam, pozwalają na określenie przedrostka dla tabel w bazie danych. Do tego można na potrzeby jednego z serwisów wystawić sobie coś a la web service i dopiero za jego pomocą wybierać dane. Jak się nie da to trzeba by tylko posiedzieć i zrefaktrować zapytania by sie kupy trzymały z nazewnictwem.
Swoją drogą robiłem współpracę dwóch baz w ramach pracy licencjackiej i zamiast joinów używałem podzapytań. Jednak nie zawsze się tak da.
0
w jednej bazie to jest pikuś, zresztą jest już świetny gotowiec. w dwóch bazach na jednym serwerze też jest to dosyć proste. ale dla własnej satysfakcji próbuję pokonać barierę niezależnych serwerów (co samo w sobie jest ciekawym problemem) ;-)
0
vixen03 napisał(a)
w jednej bazie to jest pikuś, zresztą jest już świetny gotowiec. w dwóch bazach na jednym serwerze też jest to dosyć proste. ale dla własnej satysfakcji próbuję pokonać barierę niezależnych serwerów (co samo w sobie jest ciekawym problemem) ;-)
E tam od razu problemem. Rozwiązane chyba w latach 90-tych, jak nie wcześniej (czyt. prehistoria).
Załóżmy, że mamy tabelę Ra w bazie A oraz Rb w bazie B na drugim serwerze, które łączymy po kolumnach a = b. Wynik chcemy mieć na węźle A.
Metoda 1, naiwna - dobra, jeśli wiemy, że większość krotek się złączy: Węzeł A wyciąga ze swojej bazy całą kolumnę a, pakuje, wysyła do węzła B. Węzeł B dokonuje złączenia klasycznym algorytmem (np. merge join, hash join, INL, BNL), przesyła wynik złączenia do węzła A. Węzeł A dołącza pozostałe kolumny tabeli Ra klasycznym złączeniem i zwraca wynik.
Metoda 2, "dla zaawansowanych" - węzeł B hashuje kolumnę b w niewielki zbiór wartości H, o wielkości tego rzędu, co spodziewana wielkość wyniku złączenia (szacowane ze statystyk). Zbiór H jest wysyłany do węzła A. Węzeł A hashuje swoją kolumnę a i zapamiętuje te krotki, których hashe są w zbiorze H. Następnie węzeł A wysyła węzłowi B wartości kolumny a wybranych krotek i reszta jak w metodzie 1.
Metoda 2 ma jeszcze taką odmianę, że można zacząć na węźle A, i po znalezieniu pasujących hashy nie przesyłać pojedynczej kolumny, tylko od razu całe krotki, ale wtedy jest ryzyko, że prześlemy trochę za dużo (za to jest o jedną wymianę komunikatów mniej).
Tyle teorii. Algorytm prosty. W PHP da się zaimplementować, o ile baza pozwala używać tabel tymczasowych.
BTW. Na MySQLu może być taki mały zonk, że on nie umie robić złączeń inaczej niż przez INL (Index Nested Loops) tudzież naiwny NL (Nested Loops), co daje tragiczną wydajność przy złączaniu 2 tabel, w której OBIE RÓWNOCZEŚNIE mają więcej niż powiedzmy kilkaset rekordów.