Názory k článku Řízení změn záznamů v relační databázi II.
-
Nějak se nemůžu zbavit dojmu, že je tahle série článků jedna velká komedie. Myslím, že problém nespočívá v tom, že by čtenáři nechápali „základní principy chování historie dat“, ale spíš jim nestačí informační hustota článku. Snaha o pseudovědecký výklad je tristní a působí akorát komicky.
Je to škoda, protože v minulém díle dostal autor řadu doporučení, na které mohl reagovat a sérii korigovat. Takhle to akorát sklouzává na úroveň „běžný prací prášek a náš Super Prací Prášek (c) - vy zíráte, my zíráme, to je ROOT.CZ“ :-D
-
motyq (neregistrovaný)
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.
-
Tematika, ktera je v clanku popisovana resi temporalni databaze - https://cs.wikipedia.org/wiki/Tempor%C3%A1ln%C3%AD_datab%C3%A1ze pripadne obsaznejsi v anglictine https://en.wikipedia.org/wiki/Temporal_database
-
Já se obávám, že autor si myslí, že řeší úlohu jako TDB, ale k tomu mu tam chybí půlka časových dat a co je horší - ještě mu to nedošlo. Následkem toho plete dohromady výroky "platnost v DB" a "platnost v reálném světě".
Pokud toto prodává, tak patrně jeho zákazníci dostanou něco jiného než si myslí a co hůř, oni se to pak snaží používat k věcem, které si myslí že to umí.
-
vlasta (neregistrovaný)
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ádzanie 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.
-
Filip JirsákStříbrný podporovatelKritici by měli ukázat reálnou implementaci. Uvádění linků a ohánění se teorií asi nic neřeší.
Vás se tohle netýká? Neměl by tohle udělat v první řadě autor?Náš systém je plně použitelný.
Aspoň že už to netajíte. Ale nemělo by to být uvedené také v článku? -
vlasta (neregistrovaný)
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.
-
Palo (neregistrovaný)
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.
-
vlasta (neregistrovaný)
Systém je postaven v.Net v C#. Databáze je MS SQL 2005 a vyšší.
Je potřeba rozlišit Db část a aplikační část. Celý systém je poměrně obsáhlý a komplexní. Neříkám, že by Db nešla napojit na jiný OS. Ale obsloužit ji bez našeho DDCF by byl problém. To nejde vyvinout za měsíc. Proto se asi OS WIN nevyhnete.
Odladěné to je na desktopové aplikaci, ve WinForms. Neměl by být problém pro WPF. V MS SQL nejsou záměrně žádné špeky. Použít jinou DB by neměl být problém, Db by měla umět uložené procedury. Řada věcí se musí kontrolovat na straně Db, proto jsou textové dotazy zasílané z app asi problém (velikost, duplicita, funkce a pod.). Ale použít je lze, i když je to nepohodlné.
Použít DDCF assembly pod jinou technologií nemáme ověřeno. Proto to nezmiňuji. Neděláme ani webové aplikace. Na nich to také nemáme ověřeno. Ale desktopová apka je přítulnější a přenos dat jak přes VPN nebo web services funguje skvěle. Vaši apku si programujete sami. Systém DDCF vyžaduje školení. Nepoužíváme temporální Db. Tabulky i uložené procedury musí dodržovat určité schéma. Učící křivka je velmi vysoká. Chybovost se snižuje (oproti jiným systémům). U zahajovacího projektu je třeba počítat i s odpovídajícím časem. Nebudete mít připraveny User Controls a celý background, jehož příprava významně zrychluje práce. My GUI nedodáváme. Každý z nás preferuje jiné uspořádání a pod. To neznamená, že bychom Vám nepředvedli naše řešení nebo neuměli pomoci s Vašim návrhem,
Snad Vám to pro informaci bude stačit. Bližší informace na email :)
-
vlasta (neregistrovaný)
Ještě bych doplnil. Celý systém lze postavit tak, aby byl plně funkční v základních věcech. Všechny apky budou mít firmy, osoby, číselníky, adresy, telefony, emaily a pod. Pokud rozumně navrhnete GUI, nebo použijete naše, můžete na takovém základě apku pouze rozšiřovat požadovaným směrem. Rozšiřovat funkcionalitu (formuláře) a Db. Pro různé nasazení můžete určité nepotřebné části uživateli vypnout.
Celý model byl navržen tak, aby byl pokud možno jednotný přístup v rámci oblasti - k tabulkám, procedurám, třídám i formulářům. Na emailu Vám umožním stažení funkční aplikace pro posouzení.
-
M (neregistrovaný)
Preberana tema je urcite zaujimava a OBSIAHLA. Podobne problemy riesi asi kazdy, kto v danej problematike nieco skutocne naprogramoval, preto sa mnohi citia kompetentni prispiet do diskusie svojimi podnetmi (nie vzdy konstruktivnymi :)
Neodsudzoval by som vseobecny uvod (1 diel) alebo popis zakladov vyhodnocovania zmien nad zaznamami (2 diel). Zatial vsak clanky vobec nepopisuju riesenie problemu - a tu prichadza skutocna otazka: budu vobec popisane riesenia problemovych stavov, nejake skusenosti ci odporucania? Budu dalsie diely k tejto teme? Pretoze zatial boli uvedene skor vseobecne konstatovania ci principy, ktore moze dat dokopy aj teoretik bez znalosti riesenia skutocnych problemov, ktore implementacia evidencie a riadenia zmien prinasa.
