Vlákno názorů k článku Řízení změn záznamů v relační databázi od Martin Pištora - Časové hledisko je zajímavý rys, problém je, že...

Máte pravdu. Jedná se o zacyklený případ. Můžeme klidně opravit původní špatnou hodnotu novou špatnou hodnotou. Pak musíme přistoupit na kompromis. Budete souhlasit, že můžeme mít tabulky, které se po celou dobu životnosti nebudou měnit. Určitě budeme mít tabulky, kde se hodnoty měnit budou. A budeme mít i velmi exponované tabulky, kde nám na změnách a schvalování bude nesmírně záležet.

Jednoduché, zkratkovité a dle mého názoru, špatné řešení je přepsat původní hodnotu hodnotou novou. Jsou-li obě špatně (původní i nová) pak je otázkou, která hodnota se více blížila realitě. Zda-li uchování původní hodnoty nebylo přijatelnější. V takovém případě to nemáme šanci zjistit.

U našeho řešení se jedná o způsob, kdy si takovou "validaci" můžete zapnout a to až do 39 úrovní schválení. Při vkládání exponovaných údajů můžete záznam označit (vkládat) v tzv. neschváleném režimu. A jednoduše můžete nastavit, že se na záznamy v takovém stavu nemůžete odkazovat z jiných záznamů (přes FK). Záznamy v tomto stavu musí být nejprve schváleny. Jsou-li zadány špatně, mohou být bez problémů opraveny, aniž by se to projevilo v relaci s jinými záznamy.

Jedná se tedy o určitý kompromis, jak alespoň minimalizovat případné chyby. Uznáte, že pokud si budete věřit a plnit data sám sobě, i tak se nevyhnete případné chybě z nepozornosti. Lidský faktor nelze zcela odstranit. Pokud ale nepoužijeme nějaký způsob kontroly (neříkám že zrovna naše řešení), pak je otázkou, jak dalece se můžete spoléhat na záznamy, které jsou v průběhu času uživateli měněny. Máme-li v Db miliony záznamů a tisíce možných změn, nikdo nemůže zaručit, že mé rozhodování, konané na základě uložených údajů, bude správné a v souladu s těmito údaji.

Jde o velmi zajímavou, složitou a obsáhlou problematiku, kterou se snažíme nějakým způsobem řešit a z našeho pohledu standardizovat. Chceme, a to se nám podařilo, implementovat tyto postupy na všechny tabulky (potažmo objekty). Přes GUI je zapínat, nastavovat a vypínat. Tak se při vývoji Db aplikací touto oblastí již nemusíme zabývat. Dostáváme tak spoustu volného času na řešení konkrétních problémů, spojených s tou kterou aplikací.

O tom, jestli to řešíme dobře, špatně či zcela zle, tak to nevím. Chtěl jsem pouze upozornit na to, že takové situace jsou dnes zcela běžné a o žádném optimálním řešení jsme nevěděli. Mé úvahy měly vést k zamyšlení diskutujících. Vzhledem k reakcím většiny je jasné, že tato problematika kráčí mimo ně a úplně je míjí a dlouho míjet bude.

Já Vám plně rozumím. Vím, že to záleží na aplikaci. Vím, že se to tak dělá, protože je to nejjednodužší. Vím, že to v řadě případů stačí. Vím že to komplikuje UI. Ale zase existuje nějaké "ale". Určitě jste se s takovou situací setkal. Něco vyvíjíte. Máte základní požadavky. Vývoj trvá. Čas běží. Klient platí. Proto implementujete vše co nejjednodušeji. Předáte to k užívání. A následně to máte rozšiřovat. Pak stačí jediný požadavek, mimo původní zadání, právě na nějakou kontrolu a schvalování změn nad jednou blbou tabulkou. A máte problém. Domýšlíte to zpětně, nějak to tam zadrátujete, zesložiťuje se to.

Chci říci, že tomu rozumím. Proto jsem publikoval řešení, které nás od této situace odstiňuje. My tento problém neřešíme. Nemusíme. Jednoduše to používáme. Včetně možné změny databáze. Protože, co si budeme namlouvat. Nastává doba, kdy to zákazník začíná vyžadovat. Zákazník není blbec. Ta data jsou jeho a chce je mít pod kontrolou. To je realita.

Díky za rozumnou diskusi a za link. Podívám se na to.