Mam taki "case". Od lutego będę pracował na 2 komputerach w dwóch różnych lokalizacjach (częściowo pracuję w domu częściowo w firmie, bo zmieniamy się z żoną). Rozwijam kilka aplikacji i szukam sposobów na synchronizację środowisk dev. Z plikami nie ma problemu bo jest git + serwer zdalny, na który sobie wszystkie zmiany pushuje na koniec dnia. Problem natomiast jest z bazami, bo wiadomo w czasie developerki różne rzeczy się zw bazach zmienia.

Pomysły jakie mi przychodzą do głowy to:
- baza na zdalnym serwerze, ale to się wiąże z małą responsywnością i ewentualnymi kłopotami przy przetwarzaniu większych partii danych w bazie
- skrypcik, który na koniec dnia dumpuje mi bazę do pliku na droopbox

Ale może są jakieś inne sposoby na rozwiązanie tego kłopotu - myślałem o jakichś historiach typu replikacje, ale to chyba strzelanie z armaty do wróbla + kłopot, bo jak pracuję 2 dni w jednej lokalizacji, to drugi komputer jest oczywiście wyłączony.

Oczywiście najwygodniejszy byłby laptop, ale nie chcę go wozić ze sobą, bo po drodze do pracy często robię treningi na basenie lub biegam w lesie i nie chcę zostawiać sprzętu bez nadzoru + często do pracy jeżdżę rowerem 20km w jedną stronę, więc targanie sprzętu nie wchodzi w grę (chyba, że intel kiedyś swój pocket stick wyda w rozsądnej cenie i z parametrami do developerki ;-) )

O ile więsze ilości danych będą w bazie a nie wgrywane z komputera lokalnego to całość operacji będzie wykonywana na serwerze a zwracane będą tylko wyniki. Co oznacza, że np UPDATE na 1mln rekordów będzie trwał tyle samo co na maszynie lokalnej (jeśli mają te same parametry). Jeśli natomiast przerzucasz dużo danych z dysku do bazy to różnicę będzie dało się zauważyć na słabym łączu internetowym.


Możesz połączyć to z punktem pierwszym - dump bazy na koniec pracy, wgranie do bazy na serwerze, powrót do domu i zgranie bazy z serwera do bazy lokalnej. Piszesz o większych partiach danych, zatem taki zrzut całej bazy, przesłanie na serwer i wgranie będzie zajmował sporo czasu (zwłaszcza, że zwykle łącza domowe/firmowe mają słabsze wysyłanie).

Tu właśnie przychodzi z pomocą replikacja. Dzięki temu nie będziesz przerzucać całej bazy tylko zmodyfikowane rekordy.

Źle się wyraziłem z większą ilością danych, bo u mnie to są zazwyczaj małe bazy (kilka/naście mb), ale czasami trzeba coś w projekcie przeindeksować itp i wtedy robi się sporo zapytań - zwłaszcza selectów i tu się właśnie objawia ta niewygoda bazy na innym serwerze. Nie wiem czy tylko ja tak mam, ale jak robię coś "na szybko" i jednorazowo, to często po prostu nie bawię się w optymalizację, tylko korzystam z CRUD i lecą tysiące zapytań. Bo w sumie lepiej poczekać, aż się baza przez te kilka minut przemieli niż optymalizować kod, który zostanie wywołany tylko raz na etapie programowania. Przy zdalnej bazie to niestety już będą bardzo długie czasy oczekiwania.

Im więcej o tym myślę tym bardziej dochodzę do wniosku, że chyba patent z dropboxem będzie najlepszy. Łacza w obu lokalizacjach mam przyzwoite na tyle, że wgarnie moich baz to pewnie kilka/naście minut więc zawsze wychodząc można po prostu ustawić shutdown systemu z opóźnieniem tych 30 minut.

Jeśli nie masz zewnętrznego serwera z działającą bazą to tak, przez pliki będzie szybciej. Jeśli jednak masz taki serwer, to wygodniej będzie robić update zdalnej bazy, a potem lokalnie zasysać z tej bazy.

Czy na prawdę aż taki problem jest z tym żeby używać bazy na remote?
Zrozumiałbym gdybyś miał bazę np. 40GB która pluje dużą ilością danych, ale w Twoim wypadku nie wiem czy to nie za duże kombinowanie z tymi synchronizacjami.

Od biedy możesz sobie postawić master-master-master i też będzie działać. (centralny oczywiście ten na remote.)