Vlastnosti rotačních disků (rychlé sekvenční čtení, pomalé čtení s náhodným přístupem) byl asi jen jeden z faktorů proč se rozšířily relační SQL databáze.
1. Relace (tabulky) jsou vlastně množiny, což je jednodušší abstrakce než stromy (grafy). 1D tabulka má tu výhodu, že se s ní dobře jednoduše mentálně pracuje. Když pracujete s fakturou, zajímají vás položky faktury a už vás nezajímají složky, kde je faktura zařazena. Pokud pracuji s fakturami, tak mne nezajímají položky faktur, atd. Relační model není tak obecný jako síťový, ale je dostatečně silný, a velice jednoduchý.
2. Relační databáze byly navrženy pro uživatele - umožňují neprogramátorům pracovat s daty. Tuto vlastnost konkurenční systémy nikdy ve větším měřítku nenabídly - a je to dáno možnostmi a názorností a jednoduchostí relačního modelu. Ono ručně pracovat se stromy pro laika není to pravé ořechové.
3. Relační model byl doplněný o SQL - opět jednoduchý, ale dostatečně silný nástroj. A standardizace, byť ne vždy dokonalá je neskutečně silný nástroj. Pokud umíte pracovat s Mongem, umíte pracovat s Mongem, ale už nikoliv s čímkoliv jiným. Pokud umíte SQL, tak vytvoříte tabulky a dotazy na Oracle, MSSQL, MySQL, Postgresu, SQLite. Na určité úrovni nemusíte řešit detaily a základy jsou stejné. Univerzální dotazovací jazyk nabídly pouze relační SQL databáze. Resp. byly pokusy i u dalších modelů, ale bez výraznějšího rozšíření.
4. Tabulka je implementačně halda. Struktura, která se jednoduše implementuje. Navíc v kombinaci s indexy, kterých můžete mít k haldě tolik kolik potřebujete můžete mít rychlý přístup přes různé atributy. Halda (případně pole) je velice efektivní struktura. Na uložení stromu potřebuje výrazně více paměti.
Ve výsledku je důležitá abstrakce a SQL. Obojí umožňuje pracovat s daty komukoliv. Jestli v reálu data budou uložená na SSD nebo v RAMce, jestli budou uložená v poli, v hash mapě nebo v nějaké stromové struktuře je úplně jedno .. v momentě, kdy bude dost RAM, abych data uložil na disk. Co vždy ale bude důležité, že kdokoliv, kdo má práva a trochu znalostí se může na data podívat z Excelu, z libovolné aplikace a není omezen programátorem.
Hmm tak ted nevim... :-)
Na jednu stranu jsem rad, ze se ozval odbornik.
Na druhou stranu prave kvuli tvemu hobby muze byt tvuj nazor zkresleny.
Neuvedomuju si, ze bych potkal uzivaka kterej by umel aspon zaklad SQL, nebo si napojit excel na databazi.
Mozna mam jen smulu.
Já takových uživatelů potkávám desítky ročně. Nově jsem se dozvěděl, že např. s databázemi přímo pracují intenzivně testeři. Jinak, kdekoliv, kde je databáze dostupná, a jsou v ní zajímavá data, tak se data vytěžují. U jednodušších aplikací přímo. Je to otázkou oboru, velikosti firmy, kde je několik lidí, případně celé týmy v roli datových analytiků. Většina programátorů využívá možnosti dívat se na svá data, aniž by ještě měli připravenou svou aplikaci a mohli se dívat na data skrze svůj interface.
Věřím, že se můžete pohybovat v doméně, kde přímý přístup není realizovatelný (nebo snadno realizovatelný), a pak samozřejmě, takovou zkušenost nemůžete mít. Pokud Vám někde běží databáze v hostingu, tak z venku se k ní většinou nedostanete - a v momentě, kdy ztratíte svobodu, a data analyzujete jenom prostřednictvím vyexportovaným naimportovaných csv, tak Vás to rychle přestane bavit.
Alespoň okrajově sleduji výzkum v oboru databází, a už možná déle než 20 let se čeká, až se zbavíme omezení IO. První paměťové databáze jsou tu od devadesátých let. Pak se storage části databází budou přepisovat. Ale že by se opustil relační model - k tomu není důvod. Ve výzkumu to není tak vyhrocené - a je vidět prolínání některých konceptů nebo vzájemné obohacování - praxe ukázala, že držet se dogmaticky čistoty jednoho modelu není praktické (což neznamená, že je praktické dělat opičárny). SQL dnes už není čistě relační jazyk - podporuje rekurzi, analytické funkce, neatomické typy, a k nim příslušné dotazovací jazyky XPath a JSONPath. ANSI SQL 2020 by mělo integrovat GraphQL.
241 Odpovědí
31943 Zhlédnutí