Az elsodleges problemad ugyis az lesz, hogy egy csomo tipust nem fogsz tudni megengedni a master oldalon, mert az sqlite-nak merhetetlenul minimalis az abrazolokepessege, raadasul a hivatalosan ismert tipusok egy reszet is stringkent tarolja, es beparzolja ha kell. Ezt mindenkepp el kell valahogy kezelned, dinamikus konvertalassal peldaul.
En az edit_log tablaban csak a ket kapcsolodasi ido kozti adatot tartanam a kliensen, a tobbit eldobnam. Felesleges tobbezer evnyi tortenelmet felhalmozni, a kliensnek akar korlatozott kapacitasa is lehet, raadasul adott esetben a szerveren ugyis ott a teljes edit_log.
Oszinten szolva en nem vagyok hive a "kossunk ossze sok kulonfele SQL szervert, mert az jo lesz" elvnek, mert valaki biztos olyasmit akar csinalni, ami nem mukodik a rendszerben, es csak anyazasok vannak. Inkabb csinalnek valami nagyon egyszeru kozos formatum feletti szinkronizalast (JSON pl. tipikusan alkalmas a celra), es mindenki epitgessen maganak sajat DB-t. Igy nincsenek abrazolasi problemak, nincsenek CONSTRAINT problemak, mindket oldalon az lehet, ami szem-szajnak ingere, es egy kozos formatumon futtyennek ossze, ha epp arra van szukseg.
A semavaltas meg legyen az app fejlesztojenek a felelossege, nem egy ordongosseg egyebkent megirni SQLite-ban a migraciokat, plusz amugy is kell frissitest kitolni (altalaban egy sema modositast nem ok nelkul lepnek meg), szoval mindegy. A kozos formatum meg el tudja rejteni azokat a semamodositasokat, amik nem tartoznak a kliensre (nem semabovulesrol van szo).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.