połączenie systemów, w przyszłości Opcje

[TomASS]

Witam. Dostałem za zadanie zrobienia dwóch systemów od dwóch różnych firm, które w przyszłości będą miały zostać połączone. Na razie ze względów polityczno-ekonomicznych muszą stać dwie niezależne bazy danych i dwa niezależne serwery php. Niejako "jądra" systemów są identyczne (tzn. bazy danych), ale layouty (interfejsy) będą różne. W przyszłości planowane jest połączenie dwóch systemów w jedną bazę danych (bo tak chyba będzie najlepiej). I teraz zastanawiam się jak już przyszykować się na taką fuzję? Na pewno bazy danych muszą mieć identyczną strukture, ale co w systemie? Czy na początku skryptu porobić sekcję z zapytaniami i ją modyfikować? Czy porobić odopowiednie klasy do wywołania zapytań?

[sf]

Malo danych... zalezy od tego co system bedzie mial i jak ma wygladac fuzja... trzeba przeanalizowac rozne warianty... najlepiej kupe czasu posiedziec na przeanalizowanie tego i wtedy dostaniesz odpowiedz jaki wariant wybrac.

[TomASS]

To tak, załóżmy,że jest to system sprzedaży - coś ala hurtownia internetowa i teraz dwaj producenci mają swoich klientów, swoje produkty itp. Fuzja ma polegać na tym, aby klient w przyszłości nie musiał się logować do dwóch systemów (do jednego producenta i do drugiego), tylko aby widzał wszystkie towary od dwóch producentów po jednorazowym zalogowaniu się.

[sf]

co sie stanie jesli dwoch klientow posiada ten sam login.. jak polaczysz te dwie bazy danych?(IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[TomASS]

No własnie, czyli min, o to musze zadbać na początku. Czyli aby ten sam klient w dwóch systemach posiadał ten sam ID (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) kicha, zaczyna mi się to nie podobać (IMG:http://forum.php.pl/style_emoticons/default/angrysmiley.gif)

Ten post edytował TomASS 25.09.2005, 12:16:44

[h.4]

musisz do kazdego wiersza dodac ID np A a w drugiej bazie B
narazie pobierasz dane WHERE ID = A a w drugim systemie WHERE ID = B

po polaczeniu dajesz WHERE ID = A or ID= B
co do loginow mozna zrobic ze loginem bedzie adres email lub do kazdego loginu bedzie dodawany ciag @system1 a drugi @system2

to takie moje ogole spostrzezenie, niby nic ale cos mozna jeszcze pokombinowac (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[TomASS]

Dobre (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Zaszła taka potrzeba, że te dwa systemy będą musiały działać na oddzielnych serwerach (ze względów i bezpieczeństwa i ekonomii oraz polityki firm), jednak po połączeniu systmu, chyba będzie najlepiej zrobić bazę danych i łączyć w niej dane (przed każdym zaputaniem) z tych dwóch systemów. Co o tym sądzicie?

[Vengeance]

I przy takich właśnie problemach widać dopiero, jak przydatne jest odpowiednie wykorzystanie obiektowości (ewentualnie samych funkcji).
Nie trzeba babrać się w kodzie, wystarczy jedynie połączyć w obrębie jednej metody pobieranie danych dla obu producentów.

[TomASS]

Noto ma taki plan.

• Są dwie, różne bazy, dla różnych producentów, na różnych maszynach. Załóżmy że nazwiemy je baza1 oraz baza2. Bazy są o identycznych strukturach.
• W momencie sygnalu do połączenia systemów, tworzę wspólną bazę danych o nazwie baza3, na zupełnie innym - trzecim serwerze. Strukuta idnetyczna jak baza2 lub baza3.
• W momencie gdy nastepuje modyfikacja bazy danych nr. 1 lub nr.2(INSERT/UPDATE/DELETE), jest również modyfikowana baza3.
• Każdy SELECT jest robiony ba bazie3.
• W momencie gdy baza3 przestaje działac i nie jest możlwa operacja INSERT/UPDATE/DELETE, robiony jest plik bledów i aktualizowana tylko baza1/baza2. CRON jak stwierdzi obecnosc pliku błędów, to będzie się starał uzupełnić bazę3 jak odzyska sprawność.
• W momencie gdy pada baza3 i nie jest możliwa operacja SELECT, to SELECT będzie wykonywany na bazie1/bazie2 i traci się tylko połowę danych.
• Gdy pada baza1/baza2 i nie jest możliwy do niej zapis, to tak samo - plik błędu i CRON.

Co o tym sądzicie?

Ten post edytował TomASS 25.09.2005, 22:34:52

[mike]

Są dwie, różne bazy, dla różnych producentów, na różnych maszynach. Załóżmy że nazwiemy je baza1 oraz baza2. Bazy są o identycznych strukturach.

To po co je rozdzielać. Nadmiar danych to nie powód do bólu głowy. A jak bedziesz miał połączone to łatwiej Ci bedzie wykonywać statystyki połączone. Bo związane z jedną firmą to wiadomo.

W momencie sygnalu do połączenia systemów, tworzę wspólną bazę danych o nazwie baza3, na zupełnie innym - trzecim serwerze. Strukuta idnetyczna jak baza2 lub baza3.

Zbędne zamieszanie. Nie lepiej postawić coś a'la aplikacja rozproszona: jedna baza danych i dwa front'endy. Bedziesz musiał zadbać tylko żeby prowider, u którego masz bazę pozwalał na połączenia z nią z poza localhost.

W momencie gdy nastepuje modyfikacja bazy danych nr. 1 lub nr.2(INSERT/UPDATE/DELETE), jest również modyfikowana baza3.

Ciekawe jak zadbasz o poprawność takich "transakcji". Bedzie Ci bardzo trudno kontrolować operacje na dwóch różnych bazach.

Miom zdaniem najlepszym wyjściem jest postawienie jednej bazy, z której kożystają dwie aplikacje zewnętrzne i flagowanie danych (tych, które tego wymagają: loginy, produkty, ...) z którego serwisu pochodzą.
Bedzie Ci łatwo łączyć te dane i tworzyć statystyki, zaoszczędzisz na ilościach wykonywanych zapytań (czasem jedno do jednej bazy, zamiast dwóch do dwóch baz) oraz czasie dostępu do danych i siwych włosów przy pisaniu tego (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[TomASS]

Wg. mnie też nie widziałem, żadnych plusów za tym aby rozdzielać bazy danych, najlepszym rozwiązanie jest jedna baza danych, ale na pewno ktoś mi na spotkaniu zada pytania:

(są dwie duże firmy produkcyjne)
1. Kto jest właścicielem bazy danych?
2. Kto płaci za jej modyfikacje?
3. Kto ją utrzymuje?
4. Jak jest z bezpieczeństwem? Skoro pada jedna baza jednej firmy to druga nie może funkcjonować?

A szczerze mówiąc wątpię aby przemówiło do moich pracodawców fakt w trudości przygotowania takiego projektu rozbitego na kilka baz.

Ten post edytował TomASS 25.09.2005, 22:51:00

[mike]

1. Kto jest właścicielem bazy danych?
2. Kto płaci za jej modyfikacje?
3. Kto ją utrzymuje?

Jak to kto :?:
Skoro im zależy na fuzji to muszą podzielić koszta. Przecież żadna z nich nie weźmie tego tylko na siebie.

4. Jak jest z bezpieczeństwem? Skoro pada jedna baza jednej firmy to druga nie może funkcjonować?

To jest zmartwienie hostingodawcy i administratora serwera na którym jest trzymana baza danych. A poza tym problem jest trochę wydumany, przecież na takich serwerach backupy są robione codziennie i odzyskanie danych nie jest trudne (to hostingodawcy powinno zależeć, żeby nic nie padło) a i same awarie baz danych są raczej żadkie (o ile serwer jest utrzymywany w należytym pożądku). No i przecież można ostatecznie postawić bazę zapasową/alternatywną, która będzie kopią bazy głównej robioną co jakiś czas.

A szczerze mówiąc wątpię aby przemówiło do moich pracodawców fakt w trudości przygotowania takiego projektu rozbitego na kilka baz.

To nie chodzi od miganie się od trudności. Takie rozwiązanie niesie więcej kożyści nie tylko przy implementacji ale i realnych przy działaniu. Systemy są naprawde zintegrowane i szybsze.

[TomASS]

1. Kto jest właścicielem bazy danych?
2. Kto płaci za jej modyfikacje?
3. Kto ją utrzymuje?

Jak to kto
Skoro im zależy na fuzji to muszą podzielić koszta. Przecież żadna z nich nie weźmie tego tylko na siebie.

Micke, uwież mi, że koszta dla tych firm nie robią większego znaczenia, szczególnie jeśli chodzi o bezpieczeństwo i wydanie 2-3tyś w miesiącu. Tutaj jest problem w tym, że zarówno jedna firma, jak i druga chciała by trzymać łape na tej bazie, a przeciesz nie mogą trzymać obydwie. Ja też nie mogę. Każda by chciała wpuścić swój zespół informatyków i swoje serwery aby to wszystko u nich stało. Więc jak?

4. Jak jest z bezpieczeństwem? Skoro pada jedna baza jednej firmy to druga nie może funkcjonować?

To jest zmartwienie hostingodawcy i administratora serwera na którym jest trzymana baza danych.

Mylisz się, co interesuje mojego pracodawcę, że serwer mi padł - go interesuje efekt = niemożliwość realizacji zamówień i ma w dupie moje tłumaczenie, że to przez hosting.

A poza tym problem jest trochę wydumany, przecież na takich serwerach backupy są robione codziennie i odzyskanie danych nie jest trudne (to hostingodawcy powinno zależeć, żeby nic nie padło) a i same awarie baz danych są raczej żadkie

Wcale nie jest wydumany, jeśli jest tutaj mowa o 400 pełnych ciężarówkach towaru dziennie....a awarie...abyś się nie ździwił ile płacą u profesjonalych i dużych firm za serwery i jakie są awarie.

Systemy są naprawde zintegrowane i szybsze.

Sądzę, że dla nich ważniejszą kwestią jest bezpieczeństwo niż szybkość (która i tak nie wiele by spadła).

Ten post edytował TomASS 25.09.2005, 23:10:05

[mike]

Micke, uwież mi, że koszta dla tych firm nie robią większego znaczenia, szczególnie jeśli chodzi o bezpieczeństwo i wydanie 2-3tyś w miesiącu. Tutaj jest problem w tym, że zarówno jedna firma, jak i druga chciała by trzymać łape na tej bazie, a przeciesz nie mogą trzymać obydwie. Ja też nie mogę. Każda by chciała wpuścić swój zespół informatyków i swoje serwery aby to wszystko u nich stało. Więc jak?

No, albo rybki albo akwarium (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Mylisz się, co interesuje mojego pracodawcę, że serwer mi padł - go interesuje efekt = niemożliwość realizacji zamówień i ma w dupie moje tłumaczenie, że to przez hosting.

Jak masz umowę z dobrą firmą hostingową to możesz na nich nawet dostać odszkodowania za straty poniesione złą praca bazy danych lub jej "padnięciem". A i tak to się żadko zdarza bo za bardzi im zależy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Wcale nie jest wydumany, jeśli jest tutaj mowa o 400 pełnych ciężarówkach towaru dziennie....a awarie...abyś się nie ździwił ile płacą u profesjonalych i dużych firm za serwery i jakie są awarie.

To masz kiepskich partnerów hostingowych. Ja pracuję w firmie zajmującej się tworzeniem serwisów internetowych i znam temat od kuchni. Poszukaj lepszych hstingodawców (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

A tak w ogóle:
IMO lepszy sposób to jedna baza ... i.t.d.
Ale w tym wypdku możesz postawić dwa frontendy, które będą miały ten sam engine i każdy z nich swoją bazę danych, ponadto każdy bedzie miał dostęp do bazy partnera. Co w rezultacie zaowocuje połączeniem zawartości baz danych i nie będzie problemu z zachłannością i bezpieczeństwem, każdy odpowiada za swoje (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) tylko niech się nie postawią i dadzą sobie nawzajem dostęp z poza localhosta do baz danych (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)
Ale nie chcę złowieszczyć: jak Ci przyjdzie wybrać wybrać coś z dwóch baz i posortować, albo użyć skomplikowanych operacji na danych pochodzących z obo baz to zajedziesz się w php robiąc to co na poziomie bazy jest banalne (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)
I nie pchaj się w trzecią bazę danych jako połączenie, to kiepski pomysł.
Możesz co najwyżej robić sobie taki zrzut sam dla siebie co jakiś czas.



No, czas spać.
Mówią że: Robota nie Gołota. Nie ucieknie.
Ale wstać do niej i tak trzeba (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

[wojto]

Skoro obie tabele beda mialy taka sama strukture, to ja to na poczatku bym rozwazyl mozliwosc polaczenia obu tabel w jedna.
Bierzemy wieksza baze i do nej dodajemy rekordy z drugiej bazy. Wiadomo, ze rekordy beda sie powtarzaly, ale wtedy musimy wychwycic ich id i pozmieniac w tej drugiej tabeli pola z ktorymi ten rekord byl powiazany, a nastepnie dodac do wiekszej bazy z juz zmienionym id. Bylo by to napewno bardzo trudne do napisania, ale napewno nie niemozliwe, a zysk z wydajnosci bylby zapewne duzy, niz przy korzystaniu z dwoch baz danych.
Takie dzialanie na dwoch bazach danych jest nieoptymalne, bo np. gdy ktos chce kupic kilka poduktow, to zdarzy sie tak, ze dane jednego musi pobraz z pierwszej bazy, a innego z drugiej, wiec napewno to troche czasu zajmie, a tak by mial wszystko w jednej bazie.

[Synaps]

@TomASS
Wystarczy że stworzysz odpowiednią hierarchie w swojej aplikacji. Zdecydować się wtedy możesz na środowisko rozproszone ( n baz danych) i budować/modyfikować hierarchie firm centralnie, a hierarchie produktu lokalnie u klienta ( gdzie będzie ona określona przez np. produkt_id + firma_id = miejsce w hierarchi w odniesieniu do firmy). Dzięki temu będziesz mógł poźniej w prosty sposób połączyć dane z obu baz, przez np. scalenie tabel, zachowując tą samą konwencje nazwenictwa.
W logicie biznesowej swojej aplikacji u każdego klineta będzie zapisany jego numer identyfikacyjny, dzięki czemu po połączeniu danych będziesz nadal mógł wyodrebnić te elementy w hierarchi które do niego należą.

[TomASS]

@mike_mech: nie wiem czy firmy tego typu lub tego należą do "kiepskich partnerów hostingowych.". A wiesz jak to jest z odszkodowaniami? Nigdy nikt nie będzie dawał w umowie 100% działania serwisu, nawet, jeśli to będzie, żędu 99,9% to w roku system nie będzie działał ok 9h - a to już są duże i wymierne starty.

A tak w ogóle:
IMO lepszy sposób to jedna baza ... i.t.d.

Też tak myśle, ale obawiam się, że nie wszyscy, szczególnie Ci, którzy za to płacą :/

I nie pchaj się w trzecią bazę danych jako połączenie, to kiepski pomysł.

Dlaczego? Na pewno lepiej bylo by zrobić selecta.

No, czas spać.
Mówią że: Robota nie Gołota. Nie ucieknie.
Ale wstać do niej i tak trzeba 

Pobódka!!! (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

@wojto:

Skoro obie tabele beda mialy taka sama strukture, to ja to na poczatku bym rozwazyl mozliwosc polaczenia obu tabel w jedna.

Nie tabele, tylko bazy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Dzięki za zainteresowanie, czekam na dalsze opinie.

A może by się udało namówić na jedną bazę danych i na dwa różne serwery WWW+php? Może to by bylo lepsze rozwiązanie?

Ten post edytował TomASS 26.09.2005, 17:22:44

[patrycjusz]

Witam,

no to pokolei:

1. wiele baz (o odpowiednio zaprojektowanej strukturze) - jedno wspólne DAO,
2. API dostępowe do DAO - odpowiednia konfiguracja, uprawnienia itd
3. dostęp do API przez jeden interfejs - np. Webservice.

Nie widzę tutaj nic nadzwyczajnego, poczytaj o środowiskach rozproszonych,
są specjalne narzędzia do realizacji takich celów, idealnie zdaje tutaj egzamin środowisko J2EE - np. JBoss, SJSAS - późniejsza migracja i rozwój bardzo ułatwiony.
Do tego baza np. Firebird czy PostgreSQL (lub jeżeli jest kasa MSSQL/Oracle) i tyle.

pzdr patS

[DeyV]

patS - a ty tu od razu o potężnych narzędziach - jak rozwiązania problemów tego typu mogą być znaniczie łątwiejsze.

1. Baza klinetów - każdy klient ma e-mail - więc możę to być najlepszy indetyfikator osoby.
Więc podczas łączenia baz - szukamy odpowiednich e-maili i zakłądamy - że są to te same konta.

2. baza produktów.
Każdy produkt ma kod.
Do tego kodu - podczas łączenia - dodajemy prefix informujący o producencie lub dostewcy (hurtowni, czy co tam było w tym przypadku)
Dzięki temu rozwiązujemy problem ryzyka duplikowania się produktów.
A by jeszce to ułątwić, można od razu narzucić, że Id produktów w jednym systemie zaczynają się np. od 0, a w drugim - od 100000 - wtedy wystarczy to po prostu skopiować.

[TomASS]

No tak, tylko czy łączyć dwie bazy (dwóch producentów) w jedną. Tzn. zgodnie ze schematem jaki podałem? Wtedy byłby prostrzy np. SELECT, bo jak zrobić selecta z dwóch baz danych i do tego dodać jeszcze ORDER BY....

Onecnie robię klasę do obsługi dwóch baz poprzez trzecią i mam taki plan, że selecty robię tylko na bazie złączonej, a wszyskie modyfikacje (INSERT/UPDATE?DELETE) na dwóch - czyli na wspólenj bazie (nazwijmy ją baza3) oraz na bazie której ta operacja dotyczy (baza1).
W przypadku, gdy robię inserta, to dodaję element do bazy3, zwraca mi się ID i pod takim samy ID zapisuje ten element do bazy1.

W przypadku braku połączenia z bazą3 złączoną, bazy2 i aby utrzymać spójność bazy, zapisuję element do bazy2....tylko co z ID?

Ten post edytował TomASS 27.09.2005, 13:22:03