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ń?

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.

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ę.

co sie stanie jesli dwoch klientow posiada ten sam login.. jak polaczysz te dwie bazy danych?

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 kicha, zaczyna mi się to nie podobać

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

Dobre

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?

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.

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?

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.

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.

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

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.

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

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.

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.

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?


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.


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.


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

No, albo rybki albo akwarium

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


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

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 tylko niech się nie postawią i dadzą sobie nawzajem dostęp z poza localhosta do baz danych
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
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

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.

@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żą.

@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.

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

Dlaczego? Na pewno lepiej bylo by zrobić selecta.

Pobódka!!!

@wojto:
Nie tabele, tylko bazy

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?

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

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ć.

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?

Skoro ów firmy są w stanie wydać 2-3tyś miesięcznie nie rozumiem czemu zlecają budowę systemu osobie, która nie wie jak to zrobić. Taka mała dygresja

Ha! Otóż niewiele jest ludzi, którzy, powiem nieskromnie posiadają wiedzę aby to zrobić (nie chodzi mi o wiedzę informatyczną).

e tam, wlasnie, ze jest wielu.. zreszta u nas funkcjonuje trudniejsze rozwiazanie i wcale nie pracuja przy poprawkach jakcys wybitni specjalisci z kilkunasto letnim stazem ;]

Nie myl osoby merytorycznej od zespołu informatyków realizujących projekt.
Też nie za bardzo rozumiem problem, wyjaśnij kwestie:
- dlaczego firma zleca wykonanie systemu laikowi a na jego utrzymanie jest gotowa płacić 30 kilka tysięcy w skali roku? Wujek? Ciocia?
- dlaczego osoba która doskonale wie, że realizacja tego typu rozwiązania ją przewyższa podejmuje się tego?
DeyV, spotkałem się już kilka razy z takim przypadkiem kiedy firma średniej wielkości (500 osób na zmianie) przybiegała z płaczem bo chłopak "pprogramował" im system do controllingu (non stop korzysta z niego 50 osóB) w php+html i na mysql. Jak zobaczyłem rozwiązanie: 50 kilka tabel w bazie, część danych w plikach tekstowych (bo tak jest wygodniej czytać Pani Zosi w biurze rachunkowym), brak jakichkolwiek kluczy referencyjnych, powiązań nic, kompletnie nic, widok raz był generowany w smarty raz prosto w html. Odpowiedziałem wprost 15 tyś za audyt rozwiązania i opracowanie strategii na wyjście z tej sytuacji i usprawnienie całości. Zgodzili się. Dostali piękne dokumenty po dwóch miesiącach pracy i dzisiaj tworzy to i rozwija inna firma X, z którą mam regularnie spotkania - chwalą sobie moją pracę, ja chwalę ich a Klient w końcu ma system który generuje zyski a nie koszty.

Nie mam zamiaru się tłumaczyć Rozmowa troszkę zeszła z tematu....