[Jurigag]

mirki, mam taki problem, klient ma ten sam system(webaplikacja) postawiony dwa razy, bo było to robiony na szybko - po prostu w jednym systemie są inne zamówienia, w drugim innego rodzaju, jest oddzielna baza danych itd, i teraz chce abym mu scalił bazę, oba systemy korzystały ze wspólnej bazy(tj użytkownicy, firmy itd w bazie były wspólne dla obu systemów) i teraz zastanwiam się jak to rozwiązać, czy wszystko upchnąć do jednej bazy, stworzyć jakiś skrypt który odpowiednio pozmienia id dla których będzie kolizja dla tych rzeczy które mają być wspólne i te które mają nie być wpakować do innych tabel czy może #symfony #doctrine oferuje jakieś rozwiązanie już gotowe że będzie to mogło dalej stać na oddzielnych bazach ale jakoś pobierać np użytkowników tylko z jednej ? czy może w ogóle powinienem oddzielną bazę utworzyć jakoś dla użytkowników i firm itd ? te 1 rozwiązanie wydaje mi się w sumie "najprostsze" ale może znacie jakieś inne ? #mysql #php #programowanie

[paziu]

@Jurigag: jezeli jest mozliwosc trzymania tego w jednej bazie, to czemu by z tego nie skorzystac? DRY

[MacDada]

@Jurigag: Ja bym napisał skrypt, który przepisze dane. Gotowców nie znam. Zresztą, ciężko, żeby powstały, bo z reguły jedne dane są uzależnione od drugich i ciężko, żeby system sam skumał w jakiej kolejności ma wstawiać. No i dochodzą takie rzeczy jak np powiązanie danych w bazie z systemem plików (np w kolumnie jest nazwa uploadowanego pliku i jego też trzeba przenieść).

[Jurigag]

@MacDada: czyli też wszystko w jednej bazie i po prostu w jednym systemie zmienić z których tabel mają korzystać modele i tyle ?

[MacDada]

@Jurigag: Jak chcesz scalić to po całości – jedna baza na wszystko. Nie próbuj robić, że np wspólna tabelka użytkowników, a inne rzeczy w oddzielnych tabelach, bo pokiereszują Ci się relacje.

[jarek04]

Sprawa nie jest taka prosta, do odpowiedzi i opracowania planu scalenia była by potrzebna znajomość struktury całej bazy. Masz w niej pewnie relacje typu zamówienie---->pozycje_zamowienia itp. Zmiana jednego id rozsypie ci te relacje.

Najpierw trzeba przeanalizować strukturę, podjąć decyzję czy można zmieniać id i na jakie relacje będzie to miało wpływ. Następnie trzeba skorygować wiązania. Operacja wykonalna ale raczej kosztowna, wymaga dokładnego zaplanowania i przetestowania.

[MarcusPlinius]

@Jurigag: Nie zazdroszczę zadania i mam nadzieję, że policzysz klienta za to przynajmniej jak za Twoją przyszłą, nienarodzoną córkę ( ͡º ͜ʖ͡º) Skoro musisz się już z tym #!$%@?ć (a tylko takie określenie tu będzie pasowało) to nie baw się w oddzielne bazy i wspólnych użytkowników, bo nie dość że teraz skomplikujesz sobie utrzymanie systemu to za 3 miesiące będzie prośba o to, żeby jeszcze coś

[Jurigag]

@MarcusPlinius: myślę że zrobię to po prostu tak:
1. dla tabel które mają być wspólne odpowiedni skrypt który mi je zsynchornizuje/pozmienia id itp
2. dla tabel które mają być oddzielnie to wpakuje je po prostu jako oddzielne tabele
3. w drugim systemie po prostu będzie korzystały z tych oddzielnych tabel moje modele i tyle
4. oba systemy korzystają z tej samej jednej bazy

tak mi się wydaje że będzie najmniej #!$%@?

[Jurigag]

@MarcusPlinius: bo niestety problemem są też numery zamówień - są one na umowach a generowane są częściowo z numer ID - także nie mogę sobie zwiększyć po prostu o 1000 i tyle :P ale chyba po prostu źle zrozumiałem, myślę żę to co napisałem brzmi sensownie

[MarcusPlinius]

@Jurigag: Akurat numery umów dałoby się pewnie jakoś rozwiązać np. dodając do starych numerów jakiś sufix identyfikujący czy pochodzą z pierwszej, czy drugiej bazy, a nowe generować już na podstawie zaktualizowanych id (zakładam, że numery umów to zwykłe stringi).

Nawet jak zdecydujesz się tylko na synchronizację tylko jednej tabeli jako wspólnej to w pozostałych tabelach też muszą zostać powiązane pola zaktualizowane (inaczej Ci się relacje rozjadą). Druga kwestia, to czy klient

[Jurigag]

@MarcusPlinius: ta wiem, każde rozwiązanie wygeneruje jakieś problemy, co do duplikatów - no to pewnie tak, ale już akurat pisałem do innego brancha tego systemu podobne rozwiązanie także to nie powinno być problemem ( ͡° ʖ̯ ͡°)