[delphi] Lokalni SQL "cache"

[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

[Lukas L.]

jenze ja nemuzu mit aplikaci, ktera nejde, kdyz nejde "hlavni SQL" server - takze pres RDP nebo jakoukoliv vzdalenou cestu by to slo, ale neresilo by to autonomii aplikace. Nejde o to, ze by PC s aplikaci bylo mimo dosah site - ma to byt spis ochrana proti tomu, kdyz napr. je potreba ten hlavni SQL server restartovat a nebo nahodne sel do kytek. Resenim by byl samozrejme robustni serverovy HW dedikovany pouze pro SQL. Nicmene v soucasne praci na tohle muzu zapomenout - i kdybych to virtualizaoval s dalsimi servery, tak stejne potrebuji licenci na OS atd. Proto take hledam jak se vyhnout kupovani MSSQL serveru na PC aplikace.
Predstavoval jsem si to tak, ze by cache logika byla na aplikaci. V pripade nedostupnosti hlavniho SQL by proste nejakou dobu cekala s pokusem o dalsi spojeni. Zatimco apliakce by si dal jela z vlastnich dat. Hrozi tu minimalne problem z neaktualnosti dat tech pravidel a nasledne v navaznosti nejaka moznost nekonzistence dat v prehledech. Ale myslim, ze to by se dalo ozelet - proste pokud nebude spojeni, tak vsechen log transakci pujde do cache. Jedine co muze byt problem je jak efektivne udelat log tech zaznamu. Ted to mam udelane tak, ze se proste zapisuje radek, ve kterem je kod operace, osoba a cas. Tim padem ja musim parovat pomoci vnorenych selectu a joinu na vlastni tabulku vypujcku a vraceni. Kdosi chytrejsi mi poradil, ze v radku by mel byt cely zaznam - tj. pujceni, osoba, kdy a vraceni, osoba, kdy. Tim odpadne prace DB na strane informacniho systemu, ktery zobrazuje vystup (i kdyz me napadlo, ze bych na to mohl rovnou udelat view - zatim jsem to zkusil postelovat pomoci indexu a tim vyrazne zkratil cas provedeni, ale treba by to pohled jeste vylepsil).

[Marty]

Nebo rovnou indexovaný view

Mám trochu obavu, že se snažíš vyřešit problém workaroundem, kterým si přiděláš starosti.
Hlavní problém, který v případě výpadku SQL budeš řešit je synchronizace dávkových příspěvků uživatelů... Tohle dnes vůbec nemusíš řešit, protože na SQL máš vždy aktuální a konzistentní data. Případná lokální cache, kterou vymýšlíš, ti do toho všeho zavede nový rozměr konfliktů, které se mohou objevit - a ne všechny jdou vyřešit bez ztráty dat nebo zásahu admina! (typicky např. když různí uživatelé ve své cache změní stejná data)

Osobně bych se k této problematice postavil nejdříve analyticky a až poté programátorsky (ostatně to je moje práce ) - vyhodnotil si klady a zápory stávajícího řešení a shrnul rizika a přínosy variant nového řešení (vč. zajištění vysoké dostupnosti velkého SQL atd.). Uvažuj i náklady na programování a následnou údržbu složitého kódu. Výsledek pak předlož sponzorovi, možná se budeš divit

[Lukas L.]

tak mas pravdu, ze v pripade konkurencniho pristupu zapisu dat by v tom byl obrovsky problem. Takze bud se rekne, ze data aktualizuje jen jedna apliakce nebo se to bude muset vyresit v programu.

Prvni co me napadlo byla samozrejme replikace na urovni SQL serveru - ale vzhledem k tomu, ze tu apliakci pisu v podtstate zdarma, tak i naklady na dalsi veci musi byt velmi male. Zkusim si rozmyslet nejakou implementaci a kdyztak se uvidi.

[viki_]

Pokud se jedná pouze o "nekolik set radku", resil bych to trosku jinak. Ta kriticka data bych pri startu aplikace nacetl do nejake objektove struktury v pameti a nepracoval bych s tim jako s SQL. Zde uz by nebyl velky problem problem s ulozenim na lokal a opetovnym nactenim (napr. nejakou jednoduchou serializaci). Pokud by byl dostupny hlavni server , nalil bych to tam primo z nej a soucasne ulozil na lokal do nejakeho souboru.

[Lukas L.]

no jo, ale ono nejde o to stahnout si data (ala F@H) a pracovat s nima jako s jednotkou dat. Ty data se musi prubezne aktualizovat. Nejlepe v 0 case - tj. v aktualnim programu rovnou z puvodniho SQL serveru.
Na druhou stranu je potreba co nejcasteji dodavat na (hlavni) SQL server data, ze kterych se tvori prehledy. Vse by melo behat s co nejaktualnejsimi daty - tj. na strane aplikace musi mit co nejcerstvejsi pristup k udajum o lidech a o pravidlech (nevim jestli jsem tu jiz psal o strukture tech dat) a posilat co nejcastejsi informace o stavu (vypujckach/vraceni). To prvni uz jsem delal v jine aplikaci pomoci kolekce stringu - protoze tam to nebylo tak slozita struktura a pak jsem pouzival asociativni pristup k tomu "poli", takze jsem tovnou vyuzil to co mi nabizi delphi. Ale tady bude potreba mit vic informaci (coz bych si napr. predem pripravil do pohledu a ten bych jen stahoval) a pak odesilal potrebna data. Marty ma pravdu v tom, synchronizace spravncy dat, ktera se budou menit bude velmi obtizna...

[viki_]

V tom bych nevidel problem. V normalnim rezimu se prece bude neustale pracovat s aktualnimi daty ze serveru (jde jen o napsani nejakeho interface mezi objekt-SQL, pripadne pouzit nejaky ORM mapovaci nastroj). Pri ukonceni programu nebo v nejakem casovem intervalu se zapise cely aktualni stav do souboru na lokal (vzhledem k malemu objemu dat se to muze prepsat cele a nedelat nejakou rozdilovou logiku, zatez bude minimalni). Pokud nebude server dostupny a struktura nebude naplnena, nacte se to z toho souboru, to je cele. Tzn. ze v pripade nedostupnosti serveru budou k dispozici vzdy posledni pouzita data.