[delphi] Lokalni SQL "cache"

[Lukas L.]

pracuji na systemu, ktery komunikuje s MSSQL DB. Ted z DB (ruzne tabulky) taha data a nejaka tam uklada. Jak nejlepe resit to, ze vzdaleny SQL server muze byt nekdy nedostupny? Uz me napadlo udelat lokalni instalaci MSSQL express, nastavit repliakci tad. Nicmene SQL express ma omezene moznosti repliakci. Takze druhy napad byl si potrebne tabulky lokalne ukladat do "cache" a v priapde dostupnosti serveru pomoci napr. dalsiho threadu synchronizovat. V podstate se jedna o system, kde je potreba pouze cist z cizi DB par tabulek, kter se mohu menit, ale nemeni se casto a pak posilat vysledky stavu urcitych procesu (vypujcek klicu) do vlastni DB (odtud si je berou dalsi apliakce).
Co me napadlo jako jednoduche reseni je pripravit si jednoduchy accessovsky mdb soubor a na do nej se pres ADO pripojit a z nej/do nej ukladat potrebna "cache" data. Pokud pominu ADO a ruzne MSSQL servery, tak by jeste byla moznost neco podobneho realizovat napr. v SQL Firebird. To uz ale vyzaduje instalaci toho serveru atd.

Dat ze ctenych tabulek je nekolik set radku. Repliakce na lokal by mohla probihat napr. po pul hodinach. Celkove se za den zapise cca 100 transakci (vypujcek). Replikace zpet by byla tak po 1-2 min pokud bude MSSQL pristupny. Z DB stavu budou ostatni apliakce jen cist - nebude do nich nikdo jiny zapisovat (zatim). Staci pro to napojeni na MDB databazi nebo mam vymyslet neco vykonejsiho? Nebo existuje neco hotoveho (nebo jiny pristup)?

Pisu v D7 bez nejakych kupovanych komponent

[Marty]

Nejčistší by bylo opravdu použít replikaci na úrovni MS SQL. U Expressu je transakční i merge replikace jen subscriber, takže "pouze pro čtení".

Pokud toto nestačí nebo nemůžeš použít velkej SQL Server (např. Merge Replication je plně podporovaná ve Workgroup verzi SQL, tj. by to řešil třeba server se SBS, pokud někde v lokalitě je), je to o návrhu aplikace - při spuštění synchronizovat do lokálního souboru (s tím už si pracuj jak chceš) a v něm provádět všechny změny. Při ukončení aplikace nebo dávkově pak synchronizovat zpět.

Budeš ale muset v kódu ošetřit případné konflikty a hrozí hafo dalších chyb, protože se snažíš obejít něco ne úplně vhodnou cestou...

[Lukas L.]

no problem je, ze "velky" sql bych musel kupovat a licencovat. Potrebuji si z centralni DB urcite veci stahovat a posilat na ni vysledky. Nejde o to, ze by se to muselo provadet jen pri startu/ukonceni aplikace, ale musi to behat neustale pri jeji praci. V podstate data z centralni DB potrebuji cist tak rekneme 1x za pul hodiny. Jedna se o seznamy lidi a seznam pravidel. Podle tech pravidel se pak ta aplikace ridi a vysledky posila zpet. Tj. posilani tech vysledku by melo byt co nejcastejsi. Rekneme tak kazdych 30sekund a v pripade neuspechu zvysovat cas (samozrejme by se zaclo s delsim casem, protoze lze ocekavat, ze napr. protistrana je v restartu a bude zpet napr. do 5minut - nicmene protistrana muze byt uplne mrtva i treba na nekolik hodin).

Proste ta apliakce musi fungovat dostatecne autonomne do doby nez bude mit dostupny centralni SQL.

(ted to mam tak, ze se apliakce proste pripoji na vzdaleny SQL a pres ADO tam cpe query, ale kdyz protistrana nereaguje, tak to vyhodi vyjimku a prd. Potrebuji tu aplikaci rozsirit o dalsi funkcnosti a to uz by ty vypadky asi neustalo. "vypadky" nejsou nijak kriticke, ale "neco" se stane v tu nejmene vhodnou dobu a system nefunguje...)

[Marty]

Tady už po tom chceš dost advanced funkcionalitu - SQLko je navržený tak, že informační systém bys měl mít na "velkém" SQL a v případě potřeby přístupu k datům mimo potom možnost využít Express a replikovat. Ale pouze pro čtení, oboustranná replikace není v Expressu podporovaná. Microsoft si to představuje využít například pro pracovníky v terénu, kteří nahlíží do dat a podobně.

Mrknu se ještě na jednu věc, která mě trochu zvoní hlavou, ale až v pondělí, mám to v práci.

[Lukas L.]

nj, ja jsem se na ty express edice prave uz dival. Ja stavim aplikaci, ktera dodava data do informacniho systemu (ze ktereho se pak delaji prehledy atd.), ale pritom se muze stat, ze najednou spojeni nema. Uz jsem neco takoveho jednou delal - ale to bylo daleko jednodussi, protoze slo jen o jednu tabulku. tj. po urcite dobe se z SQL serveru stahnou data a pokud je to ok, tak se pouzivaji. Ten program je vyuzival tahle data jako look-up tabulku pro data ze ctecky a vysledek posila jinemu programu Tam jsem to resil kolekci stringu a bylo
Tady bych si predstavoval, ze budu mit specialni thread, ktery se bude starat o zamykani na tabulkach pri synchronizaci, osetri pripadne nepovedene synchronizace (skrze uchovani puvodnich hodnot v zaloze) atp. Hlavni thread pak bude vyuzivat par funkci nad tabulkou te cache. Otazka je - pokud uz se podari vytvorit ten mechanismus synchronizace jestli je vhodne pouzit treba jen accessovskou DB a nebo radeji instalalovat lokalne vetsi SQL - MSSQL express, Firebird apod. Moc se mi prave nechce ten PC s aplikaci zatezovat jeste SQL serverem.

[Marty]

Tak jsem nahlédl do knížky a fakt je to tak, to co popisuješ je optimálně Merge Replication - obousměrně, s tím, že to je podporované od verze Workgroup.
Nelze mít v těch vzdálených lokalitách malé servery, ke kterým by se připojovali klienti? Nebo jsou to přímo "cesťáci" s notebooky?

Možná by bylo lepší tu komunikaci se SQLkem úplně vynechat, na straně serveru rozchodit aplikační server a přes něj provádět synchronizaci. Buď to může být online, nebo dávkově - na klientu budeš mít v libovolném formátu frontu požadavků, které budeš zpracovávat tím aplikačním serverem.

Holt ale budeš muset vymýšlet synchronizační logiku a řešit konflikty, to nebude žádná legrace.


edit. a co takhle přístup k aplikaci přes RDP? To by vyřešilo i problém, kdy spojení nepůjde