Vlákno názorů k článku Řízení změn záznamů v relační databázi II. od motyq - Zrovna něco podobného potřebuju řešit (asset management). Můžete...

Zrovna něco podobného potřebuju řešit (asset management). Můžete někdo nasměrovat na nějaký hezčí článek než toto? Jde mi primárně o to jaká db je na to vhodná, zdroj dat budu (můžu) mít jako JSON dokumenty. Předpokládám, že vhodně zvolenou db (couchbase, mongodb), mi spoustu věcí pořeší sama databázová technologie.

Včera jsem měl rozběháno. K TDb, na níž odkazujete. Přiznám se, že je znám od okamžiku, kdy mi poslal link pan M. Pištora. Co jsem o tom studoval a díval se na videa, tak mi to připadá docela složité. Faktem je, že jsem na tom doposud neviděl nic postaveného. Např. mně děsí různé datové typy PK, rozhodování co je FACT a co DIMENSION - k tomu existují obsáhlé diskuse a návody. Dodnes to lidem není jasné. Neberte to ale jako kritiku. Jde o můj letmý postřeh.

Popsaný základ máme asi podobný (řízení platnosti záznamů). Není to ale jen o datovém modelu, postaveném na historii změn. Jde o celou řadu dalších věcí, které máme vyřešeny. Máme implementované např. jazykové verze. Tzn., že jednu Db a jedny data sdílí uživatelé, hovořící různými jazyky. Údaje se jim zobrazují v jejich jazyce. (musí se průběžně překládat). Pak schvalování a zamítání změn, vyřazování a obnovování záznamů. Dále jde i o objektový model, komunikaci s Db, dotazy v čase, webové služby, zaměnitelností Db, a pod. To všechno jsou funkční, ihned použitelné věci. S řadou z nich jsme se také několikrát trápily, než byly použitelné.

Pokud zmíníte TDb je to hezké. TDb v okamžiku nasazení ale řeší tak 1% problematiky. To vše okolo TDb, musíte nejprve navrhnout, naprogramovat a odladit. A u rozsáhlého projektu bych chtěl vidět dodržení plánovaného času. Proto mne vždy pobaví příspěvky typu "Já se obávám, že autor si myslí...", "...znovuvynachád­zanie kolesá...." a pod. Pokud bychom znovu nevynalézali "kolesá", pak by se vyplatilo chovat koně. Odbyt by byl obrovský.

Tím chci říci, že mohou existovat i jiná řešení. To jsem nikdy mepopíral. Kritici by měli ukázat reálnou implementaci. Uvádění linků a ohánění se teorií asi nic neřeší. Náš systém je plně použitelný. Ihned na něm můžete vyvíjet rozsáhlé aplikace. Se všemi výhodami historie změn.

Neměl jsem na mysli uvádění kusů kódu :) Spíše poukázat, co na TDb bylo již vyvinuto. Pokud je to technologie z 90. let, pak by měla být již plně zvládnutá a běžně užívaná. Je-li tomu tak, pak se pohybuji v jiné dimenzi. Db aplikace, s nimiž se dostávám do styku jsou stále dělány nějak podivně. A určitě k jejich vývoji není vhodný např. Hibernate a pod., nemyslíte?

Já mám na DDCF postaveny tři aplikace. První od podzimu 2004. Běží super, ale nebyla dotažena do detailů. Po čase jsme se k tomu principu vrátili a dodělali jsme to do finále.

A článek? Ten má pokračování a omezenou velikost. A nejsem spisovatel :) Mé vysvětlovací schopnosti jsou, jaké jsou. Tak sorry.

Tezko rict, myslim ze nejdele to podporuje Informix. Oracle pridal podporu az ve verzi 12c a resi se po pomoci dvou neviditelnych sloupcu, tzn. zatim tam neni zadna podpora na urovni heap tables. DB2 to podporuje od verze 10. SQL to podporuje od verze ISO SQL 2011.

Ja napisem nieco co som pisal uz pod minuly clanok. UNIVERZALNE riesenie historie a verzovania udajov NEEXISTUJE pretoze vsetko zalezi od POZIADAVIEK. Niekde staci auditacna historia zmien, niekde musite mat skutocne verzie udajov s platnostou OD - DO, moznostou opravy preklepov bez zavedenie verzie, ... proste vsetko zavisi len a len od POZIADAVIEK a od toho sa potom odvija aj samotna struktura/model udajov ktore chcete evidovat. Tieto poziadavky sa mozu menit od entity k entite a mozete mat rozne poziadavky na evidenciu v jednom systeme.

nemáte pravdu :)

Dakujem, vzdy citim ze sa mylim ked ludia so mnou suhlasia. ;-)