[delphi] Lokalni SQL "cache"

[viki_]

On ale pise, ze potrebuje udelat par set transakci lokalne, kolik transakci ma ta vzdalena databaze? Jestli navrhujes napsat interface, kterej bude udrzovat delta rozdily lokalne, muze to bejt docela pekna naloz...

Mozna jsem to jen spatne pochopil, ale z prvniho prispevku jsem ziskal dojem, ze se nejedna o nejaky velky objem dat. Tech cca 100 zapujcek ("transakci") snad neni mysleno jako 100 databazovych transakci na lokale (jaky by to melo smysl ?), ale jako aktivnich operaci (nacteni/zapis dat ze serveru/na server) ?
O zadnem interface na zpracovani rozdilu zde prece nebyla rec.

[JoeBoB]

Myslel jsem to tak, že pokud chceš mít local backup (na kterym pak lokálně pracuješ), musíš si zálohovat veškerý transakce tý vzdálený databáze a to nemusí být zanedbatelný objem dat. (možná to chápu špatně a těch pár set záznamů je celkový objem...)

[Lukas L.]

jsou to dve veci. Jde o system, ktery se bude starat o vedeni "vypujcek". Na jedne strane jsou informace o lidech a o pravidlech (komu co lze vypujcit). To jsou data, ktera se moc nemeni a mohla by byt synchronizovana k aplikaci rekneme v radu minut. A pak jsou data o tech vypujckach (a do budoucna i o jinych vecech, ale nebudeme to komplikovat), ktera by se mela do hlaviho SQL serveru synchronizovat co nejcasteji.
Ted to mam udelane tak, ze na na PC na siti bezi app a nekde jinde bezi SQL server. Kdyz se SQL server restartuje a nebo (coz se tedy jeste nestalo) prestane jit sit, tak ta app nemuze fungovat. Takze potrebuje mit nabufferovano jak informace o lidech a pravidlech, tak i stavy vypujcek.
Tady nastava ten problem, ze jsem to ze zacatku pojal dost zjedodusene. Mam to udelane jako typ eventu, datum&cas a clovek. Tzn. ze pak ke kazdemu vraceni hledam v te same tabulce pribuznou (posledni) vypujcku a cloveka co jsi to pujcil a vratil (coz mam ne moc optimalizovane reseno pres join na vlastni tabulku s funkci MAX na datum&cas a pak 2x join na tabulku lidi...). Tohle by se synchronizovalo docela dobre, protoze by se proste pri vytvoreni patricne udalosti jen odeslal sled vytvorenych udalosti (kdyz pominu, ze je potreba kontrolovat jestli uz neni vraceno atd. ale nektere tyhle problemy se eliminuji z podstaty veci).
Naopak - nekdo chytrejsi mi poradil, ze mam udelat design tabulky jako jeden radek, ked budu mit cas a osobu vypujcky a az dojde k vrace, tak zapsat vraceni. Pro prohlizeni vysledku by pak stacil obycejny select (pripadne z joinem na tabulku lidi...). Ovsem proto aby tyhle data mohla jit synchronizovat, tak by je musela mit ta app vsechan a nebo alepson informace o "otevrenych" vypujckach.

Nepredpoklada se, ze by existovala jeste jedna nebo dalsi app, ktere by vytvareli tyhle informace, ale robustni navrh by s tim mel asi pocitat... Delam to hlavne z toho duvodu, ze ta aplikace musi mit schopnost autonomniho provozu za vsech okolnosti a nemuzu si dovolit si k tomu kupovat SQL server co umi napr. merge repliakci (jak uz to popisoval Marty)...