Vlákno názorů k článku Řízení změn záznamů v relační databázi od exo - Za mne taky obecně vyjádřené. Zajímavý příklad z...
-
exo (neregistrovaný)
Za mne taky obecně vyjádřené. Zajímavý příklad z praxe, ale bez jakýchkoliv dalších přesnějších popisů řešení.
U nás taky neustále řešíme podobné problémy. Za mne je řešení dost jednoduché. Prostě se k údajům které se mohou měnit přidá jeden, nebo vice identifikátorů, které se měnit nesmí. Nicméně je možné podle nich v systému následně vše dohledávat.
Tedy řekněme že k pacientovi přidáme nějaký jedinečný nesmyslný identifikační kód. Něco co se bude inkrementovat automaticky vždy o jedničku 000001, 000002, ..., 999999. Ve všech ostatních částech databáze se nebudu nikdy odkazovat na RČ nebo příjmení ale na konkrétní hodnotu.
Pak není nic jednoduššího než napsat dotaz. Najdi mi všechny úkony za pacienta 000001. A žádné problémy které popisujete už dále nemusíte řešit. Vzhledem k tomu, že kód je jen váš, není to žádné státem nebo jinými okolnostmi vynucené rozlišení, nevznikne nikdy reálný důvod toto číslo změnit. Zůstane po celou životnost vaší DB stejné.
Co se týče měněných dat, jako je rodné číslo, jméno, příjmení atp, v těchto případech je nutné vyčlenit je do samostatné tabulky s platnostmi. Rodné číslo už tedy nebude přímo na pacientovi. ale v tabulce rodných čísel s platnostmi od do.
-
vlasta (neregistrovaný)
Nemohu s Vámi souhlasit. Vy jste nabídnul řešení v konkrétním případě. Já se snažil na konkrétním případě popsat realitu. A dále jsem uvedl, že tyto situace nastávají (mohou nastat) u každého objektu v rámci celé aplikace. Týkají se tedy každé tabulky. Děláte-li aktivně s databázemi, pak se shodneme, že obsluhujeme stovky tabulek entit s tisící sloupci. Seskupíme-li všechny sloupce (např. dle názvu), pak se jejich počet sníží. Každý z nich může měnit hodnotu. Vaše řešení říká, že pak pro každý sloupec vytvoříte novou tabulku, kam budete ukládat změny. K původním stovkám tabulek s entitami, Vám pak přibydou stovky tabulek s hodnotami. Rozumím-li tomu správně. Pak bych chtěl vidět ty selecty!
Já uvádím, že tato situace (změny) se týkají jakéhokoliv objektu (tabulky) a říkám, že je toto jedna z nejsložitějších disciplín, konzumující nejvíce času na řešení. Nám se to povedlo zobecnit a tak sjednotit celý přístup. To vše se zjednodušilo. Z Vašeho navrhovaného řešení mám pocit, že se to spíše zkomplikovalo. -
... ale houby, předřečník mám pravdu.
Dokud budete říkat "děláme to skvěle, vyřešili jsme to", tak ten článej je jen reklama a vaše příspěvky o ničem.
Pokud byste napsal princip fungování tak by to byl technický článek. Takhle to svádí k tomu, že se něčím nechcete pochlubit. A z "K původním stovkám tabulek s entitami, Vám pak přibydou stovky tabulek s hodnotami." mi vychází, že jste se vykašlali na normalizaci a máte všechno v tabulkách možná 1NF. A takovým návrhem bych se taky nechlubil.
To bude hodně řídká databáze, ale on to hardware unese, že?
-
vlasta (neregistrovaný)
Jsem rád, že jste se ozval. Vždy si vážím lidí, kteří znají toto řešení lépe než já a dokážou ihned odhalit jeho princip :)
Nikde jsem neuvedl, že to děláme skvěle. Uvedl jsem a uvádím, že se na problematiku dívám trochu z jiného, poněkud nestandardního, úhlu pohledu a k tomu potřebuji i nestandardní řešení. Stále se bavím o desktopové aplikaci a RDB. Smyslem není Vám, či ostatním čtenářům, cokoliv prodat. Smyslem je, vést diskusi na dané téma. Popíšete-li Vaše zkušenosti a nastíníte-li Vaše řešení, určitě se pohneme dále, aniž bych od Vás, respektive jiných diskutujících, vyžadoval konkrétní ukázky kódu a Db modelu. Já jsem reagoval pouze na příspěvek @exo. -
;-)
To víte, tak to dopadá když máte super řešení, ale nikdo neví jak funguje. To je velký prostor pro divoké spekulace. viz např. revoluční EM pohon http://www.osel.cz/9118-jak-vypada-situace-okolo-mikrovlnneho-em-pohonu.html
Snažil jsem se Vás vyprovokovat k technické diskusy, ale zase dostávám jen plané řeči. Tak mohu zas jen spekulovat.
Buď to nesmíte publikovat (což respektuji, jen je to třeba přiznat) a v tom případě je článek jen reklama.
Nebo to je "nepříliš hezké řešení", máte obavy z reakcí pod článkem a i v tom případě je článek jen reklama.
Říkáte že "Smyslem je, vést diskusi na dané téma.", tak ji veďte, prosím. Své - i pro NEdatabázistu špatné - řešení jsem popsal, o Vašem zjednodušujícím řešení jsem se ještě nedozvěděl ani slovo.
-
"Smyslem je, vést diskusi na dané téma."
To jako fakt? Tak, krucinal, dodejte neco, o cem se da rozumne bavit. System "Mame reseni a nerekneme nikomu, jak funguje" je fakt na tri veci.
A, mimochodem: Slova "Vždy si vážím lidí, kteří znají toto řešení lépe než já a dokážou ihned odhalit jeho princip" jste si opravdu, ale opravdu mohl odpustit. I kdyz ... take o necem vypovidaji.
-
Filip JirsákStříbrný podporovatelUvedl jsem a uvádím, že se na problematiku dívám trochu z jiného, poněkud nestandardního, úhlu pohledu a k tomu potřebuji i nestandardní řešení.
Mohl byste napsat, co je na vašem úhlu pohledu nestandardního? To, že se v databázi ukládají historické hodnoty, je standardní věc. Snad v každé příručce, kde se řeší základy, najdete nějaký příklad na trigger, který historická data odkládá. Nestandardní je asi vaše řešení, ale o tom nevíme nic. -
NULL (neregistrovaný)
To je fakt. Dočetl jsem až sem a dozvěděl jsem se jenom to, že aplikace defaultně vybírá záznamy podle
<pseudo>
datum ->List<ID.record> (třeba nějaké UID), namísto obvyklého selectu na ID (třeba nějaké UID) -> List<datum.record>.
</pseudo>A ještě to že je to nějaké neobvyklé řešení . . . nic víc.
A stejně to jenom záleží na tom, jestli má z pohledu aplikace větší smysl zobrazovat data nejprve k danému datu a nebo spíš první radši všechna data vzhledem k uživateli a pak až třídit podle jejich data (času)
-
Karel (neregistrovaný)
Jen bych doplnil, že takto se to běžně řeší v logistických, výrobních, ERP apod. systémech. Dané věci je přiřazeno konkrétní, neměnné a unikátní ID. Obvykle sekvenční číslo. A pak se v jiné tabulce sledují reference. Těch může být více, mohou mít časovou platnost, mohou být navázané na další číselníky, například číselník zákazníků.
U příkladu s rodným číslem mám prostě člověka s ID 1234. A v jiné tabulce mám napsáno, že člověk 1234 (klíč člověka) měl rodné číslo (typ reference) od 1.1.1990 do 12.12.2014 (časová platnost) 930101/1234 (hodnota reference). Pod tím mám záznam, že člověk 1234 měl rodné číslo od 13.12.2014 do nekonečna 935101/4567. Stejně tak sleduji co měl kdy za zdravotní pojišťovnu, jak se jmenoval, kde bydlel.
V případě kusovníku položek v ERP systému pak reference k položce 1234 mohou být:
Model number, od 1.1.2000 do nekonečna M1234
Čárový kód, od 1.1.2000 do nekonečna 1P1234
Číslo položky zákazníka, zákazník 11, od 1.1.2000 do nekonečna M6x30
Číslo položky zákazníka, zákazník 12, od 1.1.2000 do 31.12.2015 M6x30
Číslo položky zákazníka, zákazník 12, od 1.1.2016 do nekonečna "šroub M6 D30 válcová hlava křížový"Jak je zřejmé, jedná se o úlohu velmi běžnou a řeší se jak píšete: unikátním nic neříkajícím ID. Případné reference (rodné číslo, číslo položky zákazníka, sledovací číslo zásilky atd.) se řeší samostatnou tabulkou, kde je reference uložena pro relevantní identifikaci. Ta obvykle sestává ze sady ID, protože jen někdy stačí ID primárního objektu. Častěji musíte přidat i něco dalšího, například id zákazníka, id dodavatele, id přepravce atd. Framework tohle není schopen sám uhádnout, vždy se to musí nakonfigurovat ručně. Stejně tak se ručně musí uzpůsobit formuláře, sestavy atd.
-
v.sp (neregistrovaný)
To mi připomělo jeden zajímavý problém z bankovního systému: ani tohle unikátní ID neřeší všechno. Co když mi někdo ukradne občanku a založí si na ní účet/úvěr? Když tohle banka zjistí, musí klienta rozdělit na dva. Jeden (já) bezproblémový, druhý (ten zloděj) ve vymáhání, policejním vyšetřování apod. A o tom druhém přitom neví nejspíš vůbec nic (jméno, adresu, RČ).
