[Obecné] Lokalní a hlavní DB - synchronizace

[neonn]

Zdravim... mam problem s programem, ktery by mel pouzivat 2 databaze pro ukladani dat pro pristup online a offline... nevim, jaky zpusob synchronizace pouzit... mam 2 databaze:
1) Hlavni (DB1)... nejspise to bude MySQL. Na ni budou ulozene vsechny data. Ale je tu problem... ta DB je pristupna pouze pres VPN.
2) Lokalni (DB2)... na 99% to bude SQLite. Mela by to byt kopie dat z hlavni DB.

DB2 planuju proto, ze uzivateli nemusi jet internet nebo muze DB server spadnout (clovek nikdy nevi )... navic prace na lokalni DB bude urcite rychlejsi. Ale nevim, jakym zpusobem vyresit synchronizaci...
Muj plan je, ze aplikace bude pouzivat pouze lokalni DB a o synchronizaci se bude starat zvlastni trida. Ale ted nevim...
- pristupovat k hlavni DB primo a vzdy ji celou stahovat (mluvim o DB o velikosti asi 1-2MB)
- stahovat jenom rozdily (kontrolovat datum ulozeni noveho radku nebo udelat zvlast tabulu, do ktere se budou ukladat informace, ve ktere tabulce doslo ke zmene)
- stahovat jenom rozdily, ktere budou ulozene v textovych souborech (s informaci, kdy doslo ke zmene) a na serveru pomoci cronu spoustet script, ktery zacleni zmenene data v txt do hlavni DB
- nebo to vykutit uuuuplne jinak

... fakt nevim. Jaky zpusob je podle vas nejlepsi? Velmi rad si prectu i jine moznosti, jak to udelat. Hledal jsem na internetu, ale nic jsem nenasel (ani nevim, jakou frazi hledat)...

[Ginnex]

určitě rozdílová aktualizace. Je jen na tobě, jakým způsobem. Já bych asi používal speciální tabulku updates a nastavil trigger na INSERT/UPDATE, který zapíše například primary key řádku do tabulky updates. Při updatu by program stáhnul jen tyto řádky a tabulku updates vyprázdnil. Pokud se k hlavní bude připojovat více klientů, tak je samozřejmě nějak odlišit!

[neonn]

Databaz vice klientu pouzivat bude... proto to chci nejak poradne osetrit at to je rychle a hlavne at to funguje . S triggery jsem se jeste v zivote nesetkal (ani jsem se o ne nezajimal)... mkrnu se na ne a dam vedet. Diky za napad...

[JanFiala]

Kazda veta v hlavni DB bude mit timestamp. Ten preneses i na lokalni DB. V lokalni DB budes mit nejakou dalsi indikaci (vlozen/opraven/smazan)
Pri synchronizaci zkontrolujes, zda souhlasi TimeStamp u vety v lokalni DB s hlavni DB, pokud souhlasi, provedes akci podle indikace. Pokud TimeStamp nesouhlasi, nekdo jiny vetu zmenil a ty musis resit konflikt.

[neonn]

Tak jsem tak narychlo procetl info o triggerech a vypada to dost dobre... podporuje je jak MySQL, tak i SQLite. Asi to i usetri celkem dost kodu ... diky

Diky za napad... ty timestampy me taky napdadly... docela o tom i uvazuju, protoze je to reseni nezavisle na pouzite DB. Ale tabulek v DB je skoro 30... takze by dost narostla jeji velikost . Timestampy sice muzou mit jenom hlavni (casto menene) tabulky, ale ty ostatni (male) bych musel stahovat cele.
Zatim se priklanim spis k pouziti tech triggeru... i kdyz je to reseni zavisle na pouzite DB (ale zase nejak moc uprav pri pouziti jine pouziti jine DB nebude...).

[JanFiala]

Musis zajistit, ze ti 2 uzivatele nezmeni jeden zaznam a s takovym stavem se vyrovnat.
Predstav si, ze jeden jej smaze a druhy edituje. Ty jej v DB smazes a pak budes chtit editovat, ale uz neexistuje.
A co je spravne - mit jej smazany nebo opraveny?
Tohle ti jen triggery nezajisti.

[neonn]

Diky za vysvetleni problematiky, tohle mi predtim nedoslo... musim nad tim popremyslet. Nemam v tom uplne jasno ...

V mojem pripade by (teoreticky) melo mit prednost mazani... takze by stacilo radky nemazat kompletne, ale jen nekam presunout. A pokud by doslo k UPDATu smazaneho radku, rozhodnuti o prednosti operaci by bylo na uzivateli (ja nemuzu predem vedet, co ma prednost). V pripade nouze, by nebyl problem data obnovit...

Ale nejsem si v tom uplne jisty... furt mi to vrta hlavou

[petrusek]

kolizim se da taky predchazet s trochu jinou filozofii - editace i mazani se da nahradit jenom pridavanim a pak se to synchronizuje lip - ovsem neco za neco - zase se pak ta databaze zbytecne nafukuje (je v ni komplet historie coz muze byt i vyhoda) a je o neco slozitejsi z ni ty aktualni data vydolovat

[neonn]

Radsi bych ty smazane data jenom nekam presouval... uchovavat vsechna data by bylo asi slozitejsi...