sinhronizacija desktop i cloud baze - najelegantnije resenje

imam desktop aplikaciju koja u isto vreme popunjava i desktop bazu i bazu na serveru. Ono sto me interesuje je najelegantnije resenje sinhronizavanja serverske baze sa desktop u slucaju da nije bilo interneta i da se pounjavala samo desktop baza.

Ono sto mi pada napamet je da se prebroje recordi u tabelama i da se visak rekorda outputuje u xml i insertuje u server bazu, drugo sto mi pada napamet je da svaki rekord ima jedinstveno polje recordid i da se posmatra zadnji recordid u serverskoj bazi i da se u odnosu na njega kopiraju unosi sa vecim recordid-em, i na kraju naravno copy-over table, da se uvek brise tabela na serveru i zamenjuje tabelom na desktopu. Da li neko mozda ima optimalnije/elegantnije resenje?

Najelegantnije i najbezbolnije -> Replication .
E sad pitanje za tebe da li to tvoja baza podrzava .

Potpis

Viva lollapalooza

Mogao bih da resis pomocu neke log tabele koja bi ti belezila sve update,insert i delete upite nad bazom,
koji bi se posle toga slali u nekom odredjenom vremenskom intervalu na server, i da belezis kada je zadnji
put vrsen prenos podataka prema serveru.Kada se prekine konekcija, sve promene ce se i dalje snimati u
tu tabelu na desktop bazi i kada se konekcija vrati automatski ce se preneti na server.

Potpis

"Ne menjaj nesto sto te sasvim dobro sluzi, ne trazi leba preko pogace" - Aleksandar Andrijevic

U toj situaciji ubedljivo najelegantnije resenje je replikacija, posle njega full restore desktop baze na serveru. Sve ostalo je samo bespotrebno komplikovanje.

Ako je desktop samo jedan klijent koji upisuje i u oblak onda je najjednostavnije kada zatreba pobrisati bazu u oblaku i prepisati podatek sa dekstopa.

Ako ima vise klijenata stvar je mnogo komplikovanija, mora se raditi na nivou sloga i mora podrzati sinhronizaciju novog sloga, brisanja sloga i izmene postojeceg sloga.

Kako ovo resiti zavisi od dosta toga, a nisi bas detaljisao sa objasnjenjem cemu sve to sluzi i kako treba da radi, koje su platforme na desktopu i u oblaku i slično.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

desktop je c# a baza na serveru je mysql, i ima vise korisnika, tako da replication pada u vodu sto mi nije palo napamet.

Odlucio sam se za sledecu varijantu:

kada se izgubi konekcija pocinje da se generise xml koji ce kasnije kada se povrati konekcija da se posalje na web server i da ubaci zaostale recorde u bazu. Cini mi se da je ovo najbezbolnije resenje i da nema potrebe za proverom recorda ako se uradi kako treba.

Svako ko je ikad radio sa bilo kakvom sinhronizacijom podataka zna da je ovo ume da bude nezahvalan i zaeban posao,
koliko god se cini u pocetku da je lagan. Zato i postoji replikacija.

Potpis

Viva lollapalooza

Kao što deerbeer rece replikacija za to i postoji, i veruj mi potrošićeš sate na ovaj prolem a nećeš sigurno uspeti da napraviš bolje i funkcionalnije rešenje nego devovi iz MySQL-a. Ovakve probleme je uvek bolje rešavati na sistemskom (RDBMS) nego na aplikativnom nivou.

ali replikacija je ok ako imam jednog desktop usera, ali sta cemo ako imam 2 desktop usera na razlicitim lokacijama???

Dve baze za jedan posao su generalno loše rešenje, bez obzira gde se one nalazile. A ti ih izgleda imaš i više.

Šta će ti uopšte dve (ili n baza). Dovoljna je jedna, na serveru.

Sve operacije sa podacima se ionako moraju raditi online (u protivnom ti baza na serveru ne treba). Eventualno, unos novih podataka možeš raditi i offline, pa ih kasnije podići na server. Zapiši novi record u neki xml ili ako baš insistiraš u lokalnu bazu, pa kada budeš ponovo online digni ih gore i obriši.

Ne slazem se. Postoji sijaset scenarija i strategija koje favorizuju decentralizovan sistem. To sto svima cloud peni na usta je drugi problem...

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Ja se sa tobom slažem.

Ali čovek hoće cloud koji nije cloud?!?

Pa, tehnicki sve sto je sa druge strane internet rutera je cloud (ko se seca prvih distribuiranih tehnickih dijagrama internet je predstavljan kao oblak )

Ne postoji definicija clouda, i svaki cloud provajder ce ti reci da je cloud bas ono sto oni prodaju i svaki cloud advokat ce ti reci da je cloud ono cega su oni fanboji Za neke je to salseforce, za neke amazon services, za trece azure, za cetvrte data.com, itd. U svakom slucaju mnogo marketinskog magljenja pa nije ni cudo sto ljudi ulaze u struku verujuci da je svaki udaljeni server "cloud", jer on to u principu i jeste u izvornom znacenju

U svakom slucaju, on topic, +1 za replikaciju

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Slazem se da je cloud buzzword ali mi je onda isto nelogicno kad pocnu da se raspravljaju oblacari i antioblacari. :)
Nego.. da li je uopste moguce ono sto covek zeli... da ima n korisnika sa lokalnim bazama i centralna baza, a da svaki klijent moze da ispadne u proizvoljnom trenutku i dok je offline "skuplja" promene koje ce se naknadno podici u "oblak". Meni to ne pije vodu bas