Dotaz: Protokol/formát pro přírůstkové aktualizace databází

[xkucf03]

Existuje nějaký protokol/formát pro přírůstkové aktualizace relačních databází?

Dejme tomu, že mám nějaký veřejný registr a chci nabídnout přírůstkové aktualizace – aby si lidé nemusely stahovat pokaždé všechno znova.

Teoreticky by jim šlo dát SQL skript, který bude obsahovat INSERTy, UPDATy a DELETy, ale to je jednak takové dost volné (klient musí dost věřit serveru, aby si spustil jeho SQL skript) a jednak je to platformě závislé (dialekt konkrétního DBMS a vlastně i závislost na relačním schématu jako takovém – teoreticky si klient může ukládat data jinak a SQL třeba vůbec nepoužívá – chce jen platformě nezávislý seznam změn záznamů).

(k otázce mě inspiroval zápisek v blogu: Klient-server synchronizace – konečné řešení)

Odpovědi

[logik]

Multiplatformní neee Různé databáze nabízejí různá více či méně fční proprietální řešení typu transakčních logů. Ale tato řešení jsou zpravidla stejně bezpečné, jako vykonávání SQL skriptu, či spíše ještě nebezpečnější.

Nechápu, co je nebezpečné na SQL skriptu - pro jeho vykonání lze udělat uživatele, který bude moci jen tam, kam zas z principu musí.

[xkucf03]

S tou bezpečností máš asi pravdu, možná je to zbytečná paranoia… jen je mi trochu proti srsti, aby někdo do mého systému cpal rovnou SQL. Ale ono stačí, když mu necháš třeba přístup k information_schema a on ti tam pustí SELECT s kartézským součinem přes několik tabulek.

Jde mi o formát/protokol, který by byl vhodný i pro to veřejné nasazení a umožňoval jen to nutné minimum – přidávat záznamy, aktualizovat a mazat. A ve „WHERE“ podmínce by mohl být jen primární klíč, ne nějaké vnořené SELECTy atd., stejně tak ve „VALUES“ – tam by taky měly být jen prosté hodnoty.

Na druhou stranu, čím mocnější ten nástroj bude, tím efektivnější/stručnější inkrementy se dají napsat – např.

UPDATE tabulka SET sloupec_1 = sloupec_2 + 100 WHERE id IN (SELECT …)

Místo aby se vyjmenovával záznam po záznamu a jejich hodnoty… ale zase o to víc se to dá zneužít. A o to méně je to platformě nezávislé – když už to bude SQL, tak na straně klienta potřebuji minimálně nějaký parser SQL, abych si z toho vytahal ty hodnoty a aktualizoval si svoji lokální databázi (která třeba ani nemusí být relační).

[logik]

No nějaký parser potřebuješ vždy. Akorát že k některým jazykům parsery již existují, k některým si ho musíš napsat sám.

Obecný formát pro úpravu obecných dat neexistuje. To si holt budeš muset napsat sám, udělat logovací tabulky na ně navěsit triggery a pak je v nějakém formátu vypisovat.

[ebik]

Tak si to nespustis nad produkcni databazi. Pokud je nejaka databaze prilis cenna na to, abys do ni poustel neoverenou aktualizaci v jakemkoliv formatu, tak ji nejprve pustis (klidne automaticky) nad oddelenou databazi, a pokud se to nerozbije (a je zas na tobe co vsechno nechas zkontrolovat), tak ji prelejes do te produkcni...

[Ivan]

Chces to psat sam? Anebo ti staci to koupit? Kdysi exitovala firma GoldenGate, ktera nabizala takovy produkt - dneska ji vlastni Oracle. Predtim Oracle obsahoval technologii Streams resp XStream. Dale nabizi neco podobneho Sybase - nevim presne jak se ten jejich replakacni server jmenuje.

Takovy replikacni server bud chroupe binarni redo-logy DB serveru anebo si nad tabulkami vytvori vlastni replikacni triggery. Data pak posila na aplikacni server. Tam se data filtruji podle pravidel, anebo je zpracovavaji uzivatelske pluginy.

Vsechna tahle intergraci reseni maji vlastni ad-hoc pristup ke kazde z velkych DBMS.

[xkucf03]

Určitě by to měl být otevřený software nebo alespoň otevřený standard – jde o to, aby na straně příjmu těch dat mohl být kdokoli – veřejnost – a aby si to mohl napasovat na nějaké svoje řešení. Co nejjednodušší – tzn. během dne si přečtu specifikaci a napíšu parser, nebo použiji hotovou knihovnu a už můžu přijímat aktualizace dat.

Na straně zdroje ani není potřeba nějak duplikovat data do logů – klidně může být u každého záznamu číslo verze – rostoucí ID napříč celou databází – a klient si pak vyžádá všechny záznamy novější než určité ID (tzn. než určitý časový okamžik).

Není to žádná velká věda. On by to mohl být i třeba CSV soubor (soubory) nebo nějaký jednoduchý binární formát. Jen mi šlo o to, zda nevymýšlím něco, co už tu dávno je.

[kapo]

No, když to může být třeba i CSV soubor, tak by to rovnou mohl být GIT repozitář nad skupinou CSV souborů. Klient si vždy stáhne jen rozdíl (efektivní přenos dat) a načte jen ty záznamy, které jsou novější, než ty, co má.

[Josef Kufner]

U takových řešení je pak jen dobré se zamyslet nad vhodným formátem dat, aby byl dostatečně diff-friendly, a možná i merge-friendly. Jinak to na mnoho aplikací může být velmi dobré řešení.

[xkucf03]

Ono hlavně ta druhá strana si bude chtít aktualizovat svoji databázi – tzn. udělat změny, ne všechno smazat a všechno znova nahrát. Takže ono to sice vypadá skvěle, že se použije Git jako hotový software, ale samo o sobě to nestačí, protože on dejme tomu zajistí přenos těch změn po síti, ale pak si stejně musím udělat diff a z něj pomocí nějakého nástroje (ten je potřeba napsat) zjistit, do jaké tabulky mají změny přijít, zda se má přidávat, mazat, aktualizovat, a když, tak co tzn. vydolovat z toho primární klíče, abychom věděli, co smazat/aktualizovat a vyrobit výsledné SQL (případně jiné příkazy). To je ten nejpracnější úkol a verzovací systém s ním nepomůže, leda ho může ještě zkomplikovat.

[Josef Kufner]

Pokud jako databázi používáš ty textové soubory, tak ti to pomůže hodně. Pak třeba jen necháš přegenerovat index a máš hotovo. Pokud druhá strana například jen zobrazuje připravená data, může takový přístup být velice efektivní, zejména pokud není potřeba SQL databáze.

[Filip Jirsák]

Pro použití např. ve veřejném sektoru by se mi na použití Gitu nelíbilo to, že by byl určen program, ne formát. To už tu mnohokrát bylo, a nikdy to nebylo dobré.