Hlavní navigace

Jak odvrátit zánik RDBMS

7. 6. 2016 6:21 (aktualizováno) | Michal Šalko

Jak odumírá svět RDBMS

Asi už 10 let sleduji vývoj,  jak s novou nastupující generací programátorů klesá úroveň znalostí a dovedností práci s databázemi. Vidím upřednostňování nenormalizovaných forem ukládaní dat pomocí XML a JSON, nebo jiných nenormalizovaných formátů. Myslím, že důvod jejich existence a to uchovávaní velkého množství různých typů informací nad určitými formami se absolutizuje.  S tím jak roste výkon a klesá cena hardware, tak už je neekonomické dát si práci s FDM (fyzickým datovým modelem) a zabezpečení integrity dat je ponecháváno na aplikační úrovni.

Výběry dat se realizují hlavně přímo nad kompozitními daty (XML nebo JSON) a to pomocí NoSQL databází, nebo pomocí kompositních datových typů v RDBMS(Relačních databází).

K slovu přichází ERD (Entito- relační diagram) nutně pouze v případě velikého objemu dat, kdy ani brutální sila hardware nepostačuje rýchlosti výběru nebo zpracování dat.

A klasické RDBMS opět ostrouhají. Na scéně se objevují alternatívy se sloupcovými databázemi v případě datových skladů, nebo proudnicovými databázemi v případě on-line statistického zpracování dat. Protože jsou rychlejší.

Táto úvaha je určen všem těm, kteří ještě neztratili buďto víru v RDBMS jako já, nebo ji ještě nezískali. Často špatně navržený fyzický datový model, který neodpovídá potřebám aplikací a schopnostem databáze naše odpůrce ještě utvrzuje v tom, že RDBMS je už skoro na odpis a slabým plus je, že umí dělat v transakcích.

Agilní programování a ORM (Objektovo-relační mapování)

Často se potkávám u dnešních programátorů s agilním vývojem. Pod tím slovem rozumím to, že souhrn požadavků není jasně ukončen a v průběhu vývoje se upřesňuje mění a to i celkem zásadním způsobem. To má vliv i na datový model, který je hodně dynamicko-statický. Dynamický v tom, že se musí měnit. A statický v tom, že aplikační programátoři jsou navztekaný.

Jejich problémem je ORM. Názor „DM super, ale mi již máme naprogramované ORM.“  Znamená to, že můžeme hýbat pouze s částí datového modelu, prože programátoři prostě již něco mají hotovo a nechtějí nic předělávat. Asi nejhorší zlo je ORM, které používá mapování na entity (rozuměj fyzické tabulky v databází). Pak už s FDM (fyzickým datovým modelem) nemůžete nic dělat aniž by to pánové aplikační programátoři neodsouhlasili a přitom nezačali naříkat, že oni to musí upravit támhle a jinde zase tudle.A proč by to nemělo být už jednou tak, když to funguje.

Dalším hřebíčkem do rakve ERD(entitno relační diagram) je, když programátoři puritáni generují databázi z ORM metadat. Sice metadata mohou upravovat, ale proč by si s tím dělali těžkou hlavu? Dokud vy dbáte o nějaké pojmenování databázových objektů, které v případě výskytu chyby identifikují kde co nastalo, tak aplikačním programátorům je to jedno. Oni vidí a nachází chyby na aplikační úrovni. Větší zlo je to, že datový model se takto staví ze spod. Znamená to,že aplikační programátoři vidí jednotlivé stromy, ale nevidí les.

Tatam je doba, kdy aplikační programátoři používali DAO (Data access object – abstraktní interface nad databází ) vrstvu s SQL jazykem. Nyní je vše automatizováno s jednoduchým kalkulem jedna tabulka je jedna třída.

Jak agilní programování sloučit s SQL jazykem

Položil jsem si otázku, jak můžu odstínit šílení aplikačních programátorů před FDM, kteří potřebuje změnu jako sůl ?

Před 6 roky jsem měl obdobný problém na MySQL a vyřešil jsem je jednoduše tím, že ORM jsem posunul na server.  Přístup na fyzická data přímo nebyl, ale byl přístup k procedurám pro insert, update, delete a select. Procedura přímo v sobě obsahovala SQL příkazy, které dle parametrů provedli dotaz a vraceli výsledek. MySQL umožňoval navíc vracet i několik recordsetů což bylo super, když bylo potřeba načíst nějaká složitější formulářová data. Já jsem měl pak možnost měnit pod rukama programátorů fyzický datový model tak , jak bylo potřeba vzhledem k požadavkům na databázi nebo jak to vyžadovala databáze sama.

Je pravda že databáze pro řízení výroby obsahovala kolem 100 tabulek a procedur tam bylo kolem 400. Ale fungovalo to.

Bohužel dnes je to jinak a prostor pro FDM není. Když jsem nastínil řešení tohoto problému před 2 lety aplikačním programátorům, tak jsem dostal jednoznačnou odpověď mi tak tak rozumíme SQL a ty si jediný, který umí PLSQL jazyk. A tak raději se volají funkce v ORM.

Hm. Studentka za půlroku to celkem zvládla bez problémů. Procedurální jazyk není až tak složitý. Záleží na ochotě.

Jak navrhovat datový model ?

Myslím si, že FDM je správný tehdy, když je aplikačně neutrální. Můžete přistoupit z jakéhokoliv místa a ona vrátí korektní data a přitom zabezpečí sama jak referenční, tak i datovou integritu a obchodní pravidla. Horší je když aplikační programátoři to realizují pouze na aplikační vrstvě. Pak databáze slouží jako hromádka různých dat.

A jak na datový model? Velice jednoduše. Od konceptuálního po ERD. Entitno relační model by měl být komunikační model mezi aplikačními programátoři a databázistama. Ideálním řešením je, když DAO vrstva není fyzicky mapována na FDM , ale na ERD. To umožňuje databázistům měnit strukturu FDM tak, aby odpovídal požadavkům na databázi.

Aplikační programátoři mají jednu nepříjemnou tendenci. Přizpůsobovat  datový model potřebám aplikace. Tak vzniká mnohdy reduntance dat a servisní tabulky. V případě, ale že se domluvíte na rozhraní v DAO vrstvě, tak programátorům můžete poskytnout požadovaná data, nebo provést požadované operace přímo nad FDM, aniž by Jste je tím zatěžovali.

A tak když odstíníte aplikační programátory od fyzického datového modelu tak můžete normalizovat nebo denormalizovat dle výkonu databáze. A implementovat integritu dat a obchodní pravidla. A vypálit odpůrcům SQL a RDBMS rybník.

A spíše normalizovat. :)

Přidávat nové názory je zakázáno.

DigiZone.cz: TV Philips a Android verze 6.0

TV Philips a Android verze 6.0

Vitalia.cz: Taky věříte na pravidlo 5 sekund?

Taky věříte na pravidlo 5 sekund?

Podnikatel.cz: Změny v cestovních náhradách 2017

Změny v cestovních náhradách 2017

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Vitalia.cz: Pamlsková vyhláška bude platit jen na základkách

Pamlsková vyhláška bude platit jen na základkách

120na80.cz: Na ucho teplý, nebo studený obklad?

Na ucho teplý, nebo studený obklad?

Vitalia.cz: Proč vás každý zubař posílá na dentální hygienu

Proč vás každý zubař posílá na dentální hygienu

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Vitalia.cz: Potvrzeno: Pobyt v lese je skvělý na imunitu

Potvrzeno: Pobyt v lese je skvělý na imunitu

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

120na80.cz: Horní cesty dýchací. Zkuste fytofarmaka

Horní cesty dýchací. Zkuste fytofarmaka

Podnikatel.cz: Chaos u EET pokračuje. Jsou tu další návrhy

Chaos u EET pokračuje. Jsou tu další návrhy

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

Vitalia.cz: Když přijdete o oko, přijdete na rok o řidičák

Když přijdete o oko, přijdete na rok o řidičák