Názory k článku
Nový pohľad na tradičný relačný model

Ach jo, to jsou zase moudra:
- SQL neumí odděleně definovat relace a proměnné
- SQL nelze použít jako plnohodnotný jazyk pro implementaci aplikační logiky proto že do proměnné nenarve celou relaci najednou
- v SQL nelze určit pořadí vykonávání příkazů
- optimalizátor není potřeba, má-li vývojář plnou kontrolu nad výpočtem

Z článku jsem se dozvěděl, že Bandicot umí snáze než SQL zapsat rozdíl relací, ale jinak že má své možnosti silně omezené, například spojování tabulek že lze pouze jediným způsobem, a i to jen v případě, že se spojují přes všechny atributy stejného jména i typu. Čemuž vůbec nevěřím, takový systém by postrádal důvod existence. Samozřejmě mohu použít Google a dohledat detaily, v článku bych ale rád našel aspoň čím je jazyk silný a proč se o něj vůbec zajímat.

Mimochodem, umí Bandicot projekci, která nefunguje jako SELECT DISTINCT (tzn. jde udělat výpis včetně duplicitních řádků)?

V prípade, že chcete spájať premenné pomocou operácie JOIN na atribútoch s inými menami a typmi, musíte najprv použiť operátor RENAME na premenovanie a je možné urobiť aj typovú konverziu (zatiaľ bohužiaľ iba medzi numerickými typmi).

Čo sa týka duplicitných záznamov, tak v Bandicoote to nie je možné, duplicitne záznamy neexistujú. A pravdu povediac, ani nie je dôvod aby existovali. Pokiaľ máte dva úplne rovnaké záznamy, tak ide o tú istú informáciu. Ak chcete zachytiť to, že tá istá informácia bola zadaná viac krát, môžete implementovať počítadlo (pomocou operácie SUMMARY).

Dúfam, že v druhom diely článku sa mi podarí lepšie popísať výhody jazyka Bandicoot pomocou praktických ukážok.

Díky za odpověď - ano, chybějící projekce s duplicitními řádky typicky lze obejít, třeba tak jak píšete. Neexistence duplicitních záznamů není problém, je-li databáze normalizovaná. Ta omezená spojení ale musejí při používání dost vadit - v SQL je několik typů spojení plus vnořené dotazy, a jsou k tomu důvody.

Držím palce do dalších dílů.

Rado sa stalo a ďakujem :)

Čo sa týka tých obmedzení, tak pevne verím, že nie sú problémom. Všetky operácie v SQL sú len nadstavbou nad základnými relačnými operátormi, ktoré Bandicoot implementuje.

Bohužiaľ, jeden článok ale nie je dosť na kompletné pokrytie tejto problematiky :(

Existence duplicitních záznamů a normalizace databáze jsou dvě zcela nesouvisející věci. Duplicitní řádky se klidně mohou vyskytovat i v normalizované databázi a naopak i denormalizovaná struktura může být bez duplicit.

Ano, přesně na těchto místech jsem si také říkal "WTF?!"

To že dnešní implementace RDBMS vesměs nejsou z pohledu relační algebry 100% korektní není sporu (opakovaně to konstatoval např. i E. F. Codd). Možná by nebylo od věci vyjmenovat hlavní body definice relačního modelu, porušované dnešními RDBMS a případně demonstrovat že v tomhle udělátku to tak není. Případně demonstrovat jaké to má důsledky - jako důvody těch porušení jsou totiž většinou uváděny výkonnostní důvody.

Každopádně vyčítat jazyku SQL že v něm nejde implementovat aplikační logiku, to je jako vyčítat autům že nelítají. SQL je prostě dotazovací jazyk, specifikuje výsledek nikoliv postup jak se k němu dostat.

To že bandicoot spoustu věcí neumí mne příliš neirituje - je to relativně nový projekt, takže se to dá chápat. Celkem by mne ale zajímalo jak se očekává že to bude fungovat s více uživateli (když se zamykají celé relace). Napadá men pár otázek:

1. Jaký další vývoj se očekává (indexy, constrainty, cizí klíče, ...)?

2. Pro jaké datové objemy je to míněno?

3. Jak je to s ACID vlastnostmi? Ono totiž zamykání je jenom malý kousek toho co je potřeba.

Každopádně představa že optimalizátor není potřeba protože to zoptimalizuje programátor mne skutečně pobavila. ROFL

ad 1) Co znamená "indexy jsou podporovány transparentně"? Na tom bandilabs webu není o indexech ani zmínka, nebo je velmi dobře schovaná. Znamená to že jsou vytvářeny nějak automaticky?

ad 2) No, to je taková odpověď neodpověď. Zkuste dát nějaké příklady systému na kterém jste to nasadili a jaký objem dat to zpracovalo, jak rychle apod.

ad 3) Takže například durability je řešena pomocí transakčního logu, nebo jak? Já jsem se to pokoušel vyčíst na webu projektu, ale po 3 minutách mi z toho bíleho textu na zeleném pozadí začaly slzet oči ...

ad 4) No já v článku vidím toto "Výhodou je, že vývojár má plnú moc nad tým, ako vykonať výpočet. Preto optimalizátor, ako ho poznáme z tradičných relačných databáz, nie je potrebný." což chápu tak že optimalizace operací je nahrazena důvěrou v geniálního vývojáře. Což je nesmysl, protože vývojář není schopen předvídat statistické vlastnosti dat (objem, rozdělení, ...) takže není možné určit co je optimální postup (resp. nějaký univerzálně optimální postup neexistuje).

ad 4) optimalizácia operácii stále prebieha (napríklad použitie indexu), čo neprebieha je optimalizácia v akom poradí sa majú operácie vykonávať. Ja si zase myslím, že je programátor vie s akým množstvom dát jeho aplikácia musí vedieť pracovať (teda aspoň v drvivej väčšine aplikácií) a tak isto vie, ktorá premenná obsahu aké množstvo dát a môže používať lokálne premenné pre ukladanie medzivýsledkov do pamäte (ako pri všeobecnom programovaní)

"tradicni" SQL database si muzete predstavit tak, ze SQL je deklarativni dotazovaci jazyk a exekucni plan je forma "imperativniho" zapisu. Pokud delate join nad dvema tabulkami velikosti M a N. Tak muzete rozhodnout zda pouzijete hash join( O(M+N)), nested loop ( O(M*log(N) popr. N*log(M)) anebo cross join ( O(M*N) ). Vyhoda optimalizatoru spociva v tom, ze to "rozhodnuti" odlozite, tzn. rozhodnuti nedela programator, ale udela to za nej databaze z zavislosti na tom kolik mate dat v ktere tabulce. Dale bych chtel podotknout, ze pocet ruznych "imperativnich" zapisu velice rychle(faktorialne) roste s poctem tabulek. U slozitejsich dotazu bych veril spise automatu(opti­malizatoru) nez programatorovi.

Ano, a právě proto se tyto statistiky sbírají a udržují aktuální, a potřebné informace se z nich odhadují. Jistě, jsou situace kde je to nepřesné a optimalizátor vybere špatný plán (typicky se to děje např. při dotazech nad korelovanými sloupci, při aplikaci funkcí v podmínkách nebo při odhadování velikosti výsledku joinu).

Předpoklad že tyto informace zná vývojář se ale v praxi ukazuje jako naprosto nereálné. Zaprvé vývojář nedokáže rozumně odhadnout jak se databáze bude vyvíjet (mnohdy narostou tabulky o kterých to nikdo nepředpokládal). Ale i kdyby to u jednotlivých tabulek dokázal tak neznám nikoho kdo by byl schopen spolehlivě odhadnout výsledek joinu třeba nad 10 tabulkami (pominu-li skutečně triviální případy).

Navíc jak už Ivan výše poznamenal, optimální plán velmi výrazně závisí např. na konkrétních parametrech ve where podmínce. A to nejen na úrovni jednotlivých operátorů ale i co se týká např. pořadí tabulek. Takže možnost že "vývojář to nakóduje tak aby to bylo optimální" mi přijde krajně nepravděpodobná.

Nehledě na to, že často je to uživatel, kdo přidává dodatečné WHERE podmínky tím, že si chce ve formuláři filtrovat jen určitá data (přehled zásilek od 6.6.2011 do 12.6.2011). A jako napotvoru chce jindy zase seznam zásilek položky 60080. Opravdu mu chce někdo vždy vracet 1.2 milionu záznamů a teprve na nich filtrovat? Zjevně se shodneme že "programátor ví" je cesta do pekel a "programátor nejlépe ví" je známkou hrubého nepochopení sféry podnikových aplikací, hlavní to domény RDBMS systémů.

S tím, že "programátor ví" je cesta do pekel bezvýhradně souhlasím. Programátor neví vůbec nic, ten umí jen syntakticky správně poskládat jinak nesmyslné texty (programy), ale k čemu jsou doopravdy používány většinou nemá ani tušení.

Mám zkušenosti z vývoje systému řízení výroby pro velkou firmu. A vím, že to, co se dělalo stylem "programátor ví" byl nakonec zcela nepoužitelný odpad. Rozumné výsledky z nás začaly padat, až když jsme si uvědomili, že "uživatel ví, programátor je blb" a naučili se uživatelům naslouchat. (A navíc se nám podařilo odstranit mezipatro designérů, kteřá všemu zmatku jen nasazovali korunu.) A trvalo nám víc než půl roku, než jsem jen získali představu, co vlastně uživatel potřebuje. Pak jsem udělali velice úspěšný systém, který se rozšířil i do dalších firem působících ve stejném oboru.

4) Jenže vybrat vhodný index nelze často bez znalosti statistiky uložených dat. Když mám například index nad cenou položky a jiný nad datem vložení a uživatel chce vyhledávat podle obou těchto kritérií, musí optimalizátor poznat, kde má začít, aby dotaz byl co nejefektivnější. A podobné je to přece u složitějších dotazů, které uživatel zadá třeba pomocí GUI nad více tabulkami. Optimální vyhledávací plán je závislý na filtrovacích a řadicích kritériích a pokud to databázový stroj nechá na programátorovi aplikace, programátor si bude muset napsat nějaký optimalizátor sám. To je jednoznačně krok zpět. Kdysi jsem díky nepříliš domyšlenému rozhodnutí pracoval na projektu, který začal jednoduchým modelem nad (dnes moderní) NoSQL databází, dospěli jsme k tomu, že jsme nad ní naimplementovali jednoduchý RDBMS a nakonec data skončila v klasické relační databázi. Nic proti podobným experimentům, v některých specifických doménách se může podobný přístup hodit. Ale obecně je to IMNSHO cesta do pekel.

Pokud použiju paralelu s "všeobecným programováním", ukládání mezivýsledků do lokálních proměnných funguje perfektně na jednoprocesorvých architekturách. Jakmile budu chtít výpočet škálovat a případně i distribuovat mezi více počítači, je mi klasický programovací model dost těsný a najednou se začne ukazovat, že deklarativní jazyky mají něco do sebe.

Jenže já jsem psal o případu, kdy NELZE používat stále ten samý algoritmus prostě proto, že různých dotazů (s různými vyhledávacími strategiemi) nad daným databázovým schematem může být strašná spousta (jak o tom psal koneckonců třeba Ivan). Pak máte možnost buďto systém z uživatelského hlediska svázat tak, že bude možné zadávat jenom omezenou množinu dotazů (s případnými rozsahy parametrů) nebo se zaměřit na jeden (v ideálním případě) typický případ a holt se smířit s tím, že v méně typických případech bude vyhledávací plán dost nevhodný. Třetí možností je pouze napsat si pro každou aplikaci vlastní plánovač, který ty dotazy skládá - koneckonců natvrdo napsané pořadí vyhodnocování je dá se říci mezní případ plánovače. Je samozřejmě možné kritizovat možnosti plánovače v určitém databázovém produktu, ale je řešením na plánovač úplně rezignovat, když hrozí, že se mu občas nezadaří?

Co se týče možné paralelizace vykonávání sekvenčního kódu (to je sám o sobě trochu protismysl), v některých případech to možné samozřejmě je, ale právě jen v případech, kdy nezáleží na pořadí vyhodnocování. Když napíšu


a := 2 * 2
b := 3 * 3
c := a * b


je to snadné. Jak ale v imperativním jazyce obecně paralelizovat následující kód?


a := proc1()
b := proc2()
c := a * b


Kolik programů je psáno tak, aby ty proměnné byly skutečně nezávislé a nebylo to něco v následujícím stylu?


a := 1
b := 2
while a < 30:
a := a + b
b := a + 1
end


Jakmile se programátor začne vrtat v pořadí vyhodnocení, efektivně tím brání automatické paralelizaci. Pokud zapomene na slovo proměnná (ve smyslu paměťová buňka), dává systému šanci optimalizovat podle momentální potřeby. A to se nebavíme o nelokálních proměnných, které do toho vnášejí ještě daleko větší problém.

Paralelizovat má smysl každý výpočet, který trvá delší dobu a pokud problém, který se řeší, je vůbec paralelizovatelný. Pokud ale programátor předpokládá, že operace budou probíhat v nějakém sledu (zvlášť pokud nedej Bůh pracuje stylem "napíšu pár řádek, pustím na to debugger, trasuju výpočet a koukám, co se kde mění"), má mu to kompilátor nebo virtuální stroj měnit pod rukama? A je vůbec možné rozplést imperativní program natolik, aby se paralelizace přiblížila optimu? Tady se právě podle mě tlučou dva přístupy - programátor je chytrý, dokáže se myšlenkově přizpůsobit konkrétní architektuře a program jím napsaný (ideálně v assembleru) bude optimální a nemá smysl jej měnit vs. programátor popisuje transformaci vstupních dat na výstupní, ponechá kompilátoru / virtuálnímu stroji maximální možnou volnost co se týče průběhu výpočtu a kompilátor nebo virtuální stroj zajistí optimální výpočet. Obojí mít najednou nelze.

Mě pořád není jasné pár věcí

1) Z postů o optimalizaci jsem pochopil že příliš nesledujete statistiky, takže by mne zajímalo jak poznáte který z potenciálních indexů je vhodný.

2) Kdy se ty indexy automaticky vytváří a jak dlouho existují? Mám trochu obavu že spustím nějakou operaci a bandicoot se rozhodne že vytvoří supa-dupa index. Navíc celkem podstatnou věcí je plánování diskového prostoru, a s tím ukládání nekontrolovaně bobtnajících indexů určitě nepomůže. Pokud se neukládají a pokaždé se počítají znovu, je to IMHO plýtvání CPU časem.

Nemusíte na to odpovídat v diskusi, nevím jak komplexně je to řešené. Berte to jako námět pro některé z pokračování článku.

Mám relační tabulku se zhruba patnácti miliony řádků. Znamená to, že se při každém dotazu musí procházet celá, aby se vytvořily příslušné indexy, a stroj na několik minut zatuhne ??

Znovuvytváření indexů před každým dotazem mi přijde jako nepochopení toho, k čemu jsou indexy určené.

V preferenci co nejjednodušších systémů splňujících požadavky daného projektu se asi shodneme, o tom není sporu. Každopádně jeedno moudro říká "Na každý komplexní problém existuje alespoň jedno jednoduché, elegantní a zcela nesprávné řešení."

A je docela možné že vaše požadavky splňuje bandicoot velmi dobře. Já bohužel zatím nedokážu posoudit jak moc by byl vhodný pro moje účely, je tam příliš mnoho nezodpovězených otázek (viz. výše).

To že je to nasazené na komentáře na vašem webu a na jeden maličký objednávkový systém je fajn, ale z toho se moc usuzovat nedá. Chtělo by to nějaké srovnání s tradiční RDBMS - vzít nějaký systém, naimplementovat to v obou prostředích a porovnat komplexnost kódu a výkon.

A neberte to jako nějaké shazování vašeho projektu - o tom že SQL není dokonalé není sporu. Jsou to spíš úvahy na téma "co bych potřeboval vědět abych mohl uvažovat že něco takového někde nasadím."

"Ja si zase myslím, že je programátor vie s akým množstvom dát jeho aplikácia musí vedieť pracovať (teda aspoň v drvivej väčšine aplikácií) a tak isto vie, ktorá premenná obsahu aké množstvo dát a môže používať lokálne premenné pre ukladanie medzivýsledkov do pamäte (ako pri všeobecnom programovaní)"

Čímž říkáte, že se dobrovolně vzdáváte trhu kde dominují velké RDBMS. Konkrétněji CRM, ERP, DWH a podobných věcí. Tam totiž programátor sice představu mít může, ale s ohledem na životnost produktu (10+ let) se situace několikrát změní. Znamená to tak jednou za dva roky celou aplikaci přepsat? A co třebas jen ten prostý fakt, že některé firmy mají v ERP jen pár položek (a tudíž malé kusovníky), ale obrovské množství transakcí, zatímco jiné firmy mají statisíce položek ale transakcí jen pár? Oracle databáze si s tímhle poradí, provede optimalizaci dotazu a dosahuje v obou případech slušného výkonu. S použitím vašeho SW budu muset psát ty aplikace ve dvou (no, spíše stovkách) verzích, nebo prostě čekáte, že provedu analýzu potřeb zákazníka a většině z nich řeknu "je mi líto, ale vaše data zpracovat neumím"?

Při větách typu "optimalizace není potřeba" pamatujte, že u velkých aplikací je naprosto běžné, že se bavíme o tisících tabulek, kódu napsaném stovkami programátorů, 10+ letech práce a velmi variabilním nasazení. V takovém prostředí budí věty typu "programátor ví" v lepším případě pobavený úsměv. Bylo by vhodné se na optimalizátor podívat také jako na svého druhu JIT compiler. Sice není všespásný, ale obvykle stačí k dosažení lepšího výkonu u vybraných zákazníků jen přidat jim nějaký extra index nad problematickou tabulkou, samotný programový kód se měnit nemusí. A to je k nezaplacení. Pokud se chcete bavit jen o webshopu nebo blogu, pak raději Oracle apod. nezmiňujte.

nezlobte se, ale oba Vase prispevky maji takovy nadech nadrazenosti. Pozoruji ho casto u lidi, kteri maji co do cineni s ERP systemy, s bankovnimi systemy a pod. Vite, argumentace, ze se nekdo vedome vzdava moznosti, byt v konkurenci s temi, co nabizi podnikove systemy pro koncerny je smesna.

99% vsech systemu je urceno pro firmy, ktere maji kolem 5 lidi. Vsechny tyhle systemy si vystaci se spravou dat v textovach souborech, bez transakci, trigerru a vsech tech pitomosti, co se zde neustale propaguji jako absolutni nezbytnost. Autor clanku muze byt v klidu, at uz navrhne system jak chce, pravdepodobnost ze to nasadi Daimler nebo Audi je nulova a proto muze klidne spat.

Jina vec je, ze autor akceptuje relacni systemy a dokonce je povazuje za neco prinosneho. Ale neco mu vadi a to neco se snazil zde vysvetlit. Jeho vysvetleni se zdaji byt nedostatecna a tak je to i s tim optimalizatorem. Myslim si, ze autor krecovite hleda po duvodech, proc se rozhodl s dalsimi kolegy ten projekt nastartovat. Myslim si, ze neni uprimny. Spis vidim takovou tu obvyklou snahu, jit 'trochu' jinou cestou, nez je v danem okamziku 'bezne'. Vidim tu snahu si 'zaprogramovat', 'zanavrhovat'. To je legitimni a velmi sympaticke. Ale proc to nerict?

Nyni k tomu optimalizatoru a skutecnosti, ze programator je ten 'nejlepsi optimizer'. V tom ma autor pravdu, ale ne u relacnich systemu. Tam je programator vydan na milost vyrobci databaze a schopnosti par odborniku, kteri po bedlivem studiu skutecnosti 'tak nejak vhodne' upravi ty dotazy, aby to jaz takz chodilo. Ale protoze dnes maji relacni systemy podobny dogmaticky status jako za Gallilea ta povera o Zemi jako stredobodu vesmiru, proto budou i nadale ve vsech diskuzich 'relacne verici' obhajovat sva dogmata a takovi jako autor clanku to budou mit i nadale tezke.

P.S.
Pouzivam HandlerSocket pro innodb a mohu potvrdit, ze pouzivane 'nerelacni' dotazy prinaseji skutecne 5 nasobne zrychleni a take mohu potvrdit, ze ja jako programator jsem ten mnohem lepsi optimizer uz proto, ze uvedeny system otpimalizator samozrejme nepouziva.

No, já osobně v tom žádný "nádech nadřazenosti" necítím. Každý prostě daný produkt posuzuje z hlediska potřeb oblasti ve které působí. No a Karel zřejmě působí v oblasti CRM/ERP/DWH systémů no a tak se na to dívá z tohoto hlediska, a má 100% pravdu že pro tento segment iluze "programátor je nejlepší optimalizátor" neplatí a systém bez optimalizátoru je nepoužitelný.

Snažil jsem se přijít na to pro jaký typ systémů je to vhodnější než tradiční RDBMS, nic moc mne nenapadlo. Je sice hezké že to je údajně "čistší" než SQL, ale když ani autor systému není schopen poskytnout např. nějaké údaje o výkonu pro srovnání, to je pak těžké. Ano, je možné že to je jenom experiment a nevidím na tom nic divného, přijde mi ale poněkud nezodpovědné nainstalovat to někam do firmy pro správu objednávek a neotestovat si základní výkonnostní parametry.

BTW o tom že 99% systémů je určeno pro firmy s 5 zaměstnanci, nebo že tyto systémy není potřeba stavět transakční a že data mohou klidně ukládat do textových souborů bychom asi mohli dlouze diskutovat (např. není IMHO důležité kolik má firma zaměstnanců ale spíš kolik má zákazníků, s jakými objemy dat pracuje apod).

A kolik znáte systémů které začaly jako experimenty a dnes se běžně používají i ve velkých firmách, bankách apod.? Linux? PostgreSQL? MySQL? Facebook? Projekty spadající pod Apache Foundation? Desítky či srovky dalších projektů? Ano, pravděpodobnost že experimentální projekt "prorazí" a stane se životaschopným je malá, ale přímo úměrná kvalitě a racionalitě projektu.

Rozhodně se ohrazuji proti tomu že bych tu snad lhal. Blog o výkonu jsem samozřejmě četl, nicméně má tři poměrně zásadní vady.

Zaprvé se jedná o benchmark jednotlivých operací, nikoliv systému (na což jsem se ptal já). Ono totiž jednotlivé operace mohou být zdánlivě rychlé a výkon výsledného systému paradoxně může být tristní.

Zadruhé se jedná o single-thread benchmark. Ptal jsem se jak to bude vypadat u systému ve kterém pracuje více procesů najednou, to v tom benchmarku samozřejmě není. Z toho mála co vím o fungování transakcí v bandicootu mám obavu že to bude škálovat velmi špatně - víceméně jako kdybych v tradiční DB exkluzivně zamykal tabulky. Ale třeba se pletu.

Zatřetí se jedná o benchmark (údajně) ACID-compliant systému, v jehož zdrojácích se ale při zběžném průzkumu nevyskytuje ani jedno volání fsync/fdatasync, a přímo v benchmarku se píše "The first rows show the read/write performance for a data volume (I have an SSD drive + there are no fsync/fdatasync calls)." takže ta čísla považuji za poněkud nespolehlivá.

Můžete mi vysvětlit jak zajišťujete že to co jste zapsali na disk se skutečně zapsalo a že je to konzistentní? Stačí když mne nasměrujete na místo ve zdrojácích.

Autocommit/rollback - Dusan se zajimal o to, ze by chtel spustit testovaci scripty, ktere zmeni data, zkontrolovat jestli se to povedlo a pak provest rollback, protoze ty zmeny ve skutecnosti nechce, byly jen testovaci. Jde to?

aah, jasné, najlepšie to asi vysvetlím na príklade.

Povedzme, že chceme aplikovať 50% zľavu u všetkých predajcov a ak nejaká výsledná cena je menej ako hodnota 10.0 tak to považujeme za chybu. V takomto prípade môžeme napísať overovaciu funckiu, ktorá vráti všetkých predajcov, kde sa operácia "nepodarila":

fn TestZlavy(): Predajca
{
return predajcovia extend(novaCena = cena * 0.5) select(novaCena < 10.0);
}

Výsledok samozrejme nemusí byť celá množina, môže byť napríklad len počet záznamov.

No a tento test chceme vložit na konec funkce (pokud jsem pochopil správně, že transakce - posloupnost datových úprav - je definovatelná pouze jako samostatná funkce), která aplikovala slevu. V případě, že se operace u některých prodejců "nepodařila", chceme všechny proběhlé datové úpravy v rámci funkce (= transakce) jako celek zrušit (ROLLBACK). V žádném případě nechceme částečně správná data uložit do databáze (COMMIT). Jde to?

Zásadním problémem SQL v praxi je komplikovanost vytváření tranzitivního uzávěru - řeší tohle nějak Bandicoot?

Jednoduché. Mějme relaci (idZaměstnance, jménoZaměstnance, idNadřízeného)

Nyní potřebuji vypsat všechny podřízené (i nepřímé) nějakého zaměstnance. V (čistém) SQL obecně neřešitelné.

Tedy jestli plánujete se v Bandicootu s tímto nějak poprat.

Stačí pre každú (parent, child) asociáciu udržiavať pomocnú reláciu s uzáverom:

x_closure(ances­tor_id, descendant_id, distance)

logiku na udržiavanie stačí napísať raz (buď v modeli alebo cez triggery v SQL) a viac to už nikdy nemusíš riešiť.

Ak SQL schému generuješ z nejakého generického modelu, môžeš to celé nechať generovať automaticky pre každú stromovú štruktúru v modeli.

Benefit je, že potom nie si závislý na podpore hierarchických dotazov konkrétnym DBMS.

Jasně, že se to řešit dá, různými způsoby, ale třeba ty triggery už nejsou čisté SQL, ale procedurální berlička ;-)

(A co se týče "nie si závislý na podpore hierarchických dotazov konkrétnym DBMS" - pokud to dělám přes triggery, tak ty jsou DBMS závislé, takže to mně nepomůže. Pomůže řešit to ve vrstvě "nad", což ale zase znamená roundtripy mezi DB klientem a serverem.)

Aké roundtripy? Pri obvyklých typoch dotazov (podstrom od nejakého ancestora do nejakej hĺbky, cesta od nejakého descendanta hore k nejakému ancestorovi) len najoinuješ uzáver, takže sa trochu predraží query execution, ale žiadne client-server roundripy.

To že môžeš uzáver joinovať je ale obrovská výhoda oproti nejakému čisto klientskému riešeniu, pretože poddotazy typy subtree/path potom môžeš využívať v zložitejších dotazoch práve bez potreby zbytočných c-s roundtripov.

Predražia sa tiež úpravy stromovej štruktúry, keďže treba upravovať aj uzáver. V praxi je ale väčšinou časovo kritickejšie dotazovanie než úpravy.

Používam toto riešenie aj na rozsiahle stromy (rádovo milióny uzlov) a zatiaľ ma nesklamalo.

Roundtripy jsem myslel v případě, že tam ta pomocná tabulka není nebo se udržuje z klienta - když nepoužíváme procedurální rozšíření DB (triggery).

Nezávislost na vlastnostech konkrétní RDBMS se myslím dost přeceňuje, a netýká se to jenom hierarchických dotazů. Téměř vždy vyvíjíte konkrétní DB, investujete do znalostí jejího používání, za komerční databáze dokonce platíte nemalé licence ... takže je trochu absurdní nevyužívat zajímavé vlastnosti které vám poskytuje, a hierarchické dotazy mezi ně myslím patří.

Můj osobní názor je že dokonce i v případech kdy vyvíjíte aplikaci pro více databází, je lepší mít několik persistenčních vrstev využívajících plně každou konkrétní databázi. Alternativou je zápasit s podmnožinou SQL společnou pro všechny databáze (a pak stejně budete chtít přidat podporu další databáze s jinými SQL a máte šmitec).

Význam multi-DB dosť závisí od typu produktu. Ak je to vec, cielená na inhouse prevádzku vo väčších firmách a predaj viacerým klientom, podpora viacerých DB celkom bodne, keďže v tomto prostredí sú dosť bežné rôzne rigidné politiky ohľadom toho, čo sa tam môže nasadiť a prevádzkovať. My pri väčšine aplikácii ako nutné minimum podporujeme Postgres/MySQL/MSSQL (pričom preferred option je Postgres).

Ano, tranzitivní uzávěr býval opruz, ale podpora práce s hierarchickými strukturami se postupně zlepšuje. Oracle má "CONNECT BY", PostgreSQL má "CTE" atd.

Cau Julko, skoda, ze som ten tvoj clanok necital pred statnicami :) Moja tema: Relacny model. Velmi sa mi paci ta vasa myslienka. Zapis mi pride naozaj prirodzeny. Ten JOIN sa aj mne zda obmedzujuci, ale to moze byt sposobene tvrdym navykom na SQL. Tesim sa na druhy diel clanku, ze si nieco naprogramujem ;) Drzte sa!

mi to pripada ze je to jen jina forma zapisu. a nepripada mi to nijak prinosne - jednoduche veci se daji delat jednoduse, slozite jeste sloziteji, proste normalka.

Ale forma zápisu nemá přeci se zbytkem nic společnýho. Vy zapisujete jako RE, SQL autoři zvolili bohužel jako ukecaný. Ale není problém zapisovat SQL jako RE, na to by stačilo napsat jednoduchej preprocesor.

To, co Váš systém odlišuje je možnost obecných relačních proměných, za který platíte absencí optimalizátoru. Osobně, co by mi přišlo zajímavý je Váš přístup namontovanej jako extenze do databáze. Např. napsat do postgresql patřičný rozšíření a kompilátor Bandicootu do SQL tak, aby se existující tabulky nechali na SQL optimalizátoru a bandicoot řešil jen "dočasný tabulky".

1) Jestli bych já uměl napsat optimalizátor? No za x let možná, to je ta nejsložitější část DB. Ale hlavně, proč psát něco, co už je napsané a vyzkoušené? Hledal bych spíše cesty, jak současné iplementace využít.

2) IMHO to možné je. Teda do SQL + nějakýho procedurálního jazyka, imperativní jazyk jen tak do deklarativního převést nelze. S relačními proměnými je trochu problém, ale jdou emulovat. Např. se takové proměnné budou ukládat v global temporary table a předávat se bude jen identifikace z té tabulky. Nebo normální tabulky, ale tam bych pak musel implementovat GC. Nebo je vyhodnocovat líně (to ale asi nejde vždy).
Samozřejmě nejčistší řešení by bylo do některé z opensource databáze tu podporu dopsat.

Minimálně v T-SQL je implementováno něco, co se relačním proměnným hodně podobá a implementačně by to nemusel být problém ani v PostgreSQL - existuje tam jakýsi typ typlestore - jde jen o interface.

Ad 2) No, určitě je možné přepsat Bandicoot do Assembleru, Znamená to (podle vaší logiky), že Assembler je jazyk s vyšší vyjadřovací schopností a měl by tedy Bandicoot nahradit?

Assembler je trošku extrémní případ. IMHO na základě teorií o Turingově stroji by šlo přepsat i Bandicoot QL do SQL, jen by to bylo poněkud neefektivní a obtížně čitelné.

Rozhodně neplatí, že čím více toho daný jazyk umí, tím lépe. (Tím nemám namysli až tak teoretické (Turing-complete) hledisko.) Tím nechci říkat, že by Bandicoot byl špatný, jen bych chtěl před takovou argumentací varovat. Kde jsem na tom byl?
* Někde jsem viděl článek (odkázal na něj Martin Odersky z Twitteru) o netechnických aspektech jazyka. Stručně to bylo o tom, že vlivem rigidnosti Cčka a ohebnosti LISPu teď máme dvě vážně brané implementace (to možná není to pravé slovo) OOP pro C (tj. C++ a Objective C), zatímco máme 'bžiliony' implementací pro LISP. Ve výsledku u C programátor ví, co zvolit (OC u Apple a C++ jinde, není-li nějaký speciální důvod volit jinak) a OC i C++ jsou kvalitně implementovány, zatímco u LISPu je tu nepřeberné množství (různých a často vzájemně nekompatibilních) implementací s různými chybami. Co je ve výsledku prakticky použitelnější? (Trošku jsem to pro lepší přehlednost zjednodušil, OC a C++ jsou, striktně řečeno, prostě jiné jazyky než C.) Jakkoli mám rád svobodu volby apod., je to zajímavý námět k zamyšlení.
* Jde i o již zmíněné optimalizace. Není otázka, zda jsou optimalizace možné, spíše je otázkou, jak moc jsou náročné a do jaké míry je reálné je implementovat. Assembly languages jsou téměř neoptimalizova­telné, C a C++ jsou na tom lépe a třeba JVM zvládne i takové věci jako eliminace dynamické alokacde a eliminace zamykání, protože někdy zjistí, že to nezmění sémantiku. (Zase za to platíme délkou startu nebo 'zahřátí' a menšími možnostmi ruční optimalizace.) Taky mě napadá procházení paměti v Ruby, které je v MRI snadno implementovatelné, ale poněkud nepřímočaré (a kvůli výkonu vypnutelné) v JRuby. Dále, u čistě funkcionálního jazyka není často problém beze změny sémantiky (není-li u programu účelem se zacyklit) udělat líné vyhodnocování. To u Assembleru nějaký kompilátor asi jen tak neudělá. Ano, je možné si dopomoci nějakým kontraktem. To je ale zase určité omezení programátorů (určitý kompromis). A v praxi u Scaly podobně zapsaný výraz (např. Fibonacciho posloupnost) je někdy vyhodnocován poněkud méně efektivně (asymptoticky!) než v Haskellu. Zase, mám radši Scalu než Haskell, ale ne vždy jsou větší možnosti zadarmo.
* Určitá jistota - například dynamické jazyky umožňují zajímavé věci. Ale jsou chvíle, kdy mohou programátorovi znepříjemnit život pozdějším objevením chyby nebo tichým mlčením. Díky tomu, že mnohé již lze ve statických jazycích dělat srovnatelně komfortně (obvykle jen něco málo psaní navíc), dám radši přednost statickým.

Tyto argumenty nesměřují proti Bandicootu samotnému, ale spíše proti myšlence, že expresivnější jazyk musí být prostě lepší. Někdy může být vhodnější, ale někdy taky ne.

Pokud by se srovnávalo srovantelné - funkce Bandicootu s funkcemi v SQL (ANSI SQL 2003), tak si myslím, že lze Bandicoot přeložit do SQL a dost možná by nebyl komplikovaný překlad v opačném směru. Silnější vyjadřovací schopnost je nesmyslný pojem - buďto je ten či onen jazyk výpočetně úplný nebo není - případně může být ten či onen jazyk přizpůsobený více či méně té či oné doméně.

To, co popisujete v posledním odstavci je relativně běžné v ETL. K pojmu databáze - například ANSI/SQL takový termín nezná - definuje pouze schémata. Možná by bylo pro Vás zajímavé se seznámit s stream databases. To jsou v jistém ohledu také relační databáze, a také se tam nepracuje s tabulkami.

Myslím si, že podobných projektů jako Bandicioot je (bylo) více:

http://www.ils.unc.edu/~dwest/inls258/Non-SQL.html
http://en.wikipedia.org/wiki/QUEL_query_languages
http://www.c2.com/cgi/wiki?QueryLanguageComparison

Jednak někomu SQL skutečně může trhat žíly, jednak někdy jiný zápis může zpřehlednit určité problémy - takže podobný projekt určitý smysl má. Nedovedu si ovšem představit, že by Bandicoot mohl být výkonostně jinde než SQL databáze - vychází ze stejných teoretických modelů a bude narážet na stejné hw limity - což je seq scan a fsync.

Myslím si, že by neměl být problém postavit Bandicoot třeba jako No SQL Procedural Language pro PostgreSQL. Pak by Bandicoot měl alespoň důvěryhodný db engine.

Co se týče úplnosti, je to formálně správně, ale při praktické aplikaci se něco jako 'vyšší expresivita' prostě hodí, jakkoli je to pojem problematicky definovatelný. Ale některé věci prostě nebudou 'přímočaré', takže jejich implementace 'pravděpodobně' bude 'drahá' a 'rozumný' člověk do toho 'spíše' investovat nebude. Uf, to je tu špatně definovatelných pojmů (snažil jsem se je dávat do apostrofů), ale má to velké praktické důsledky.

Asi vím jak to myslíte. Tady při srovnání Bandicootu a SQL vidím primární rozdíl v složitosti parseru. Zápis dotazu v SQL obsahuje poměrně dost cukru, což komplikuje realizaci parseru. Sémanticky ale nevidím příliš velký rozdíl - koneckonců relační proměnné lze částečně emulovat pomocí CTE.

No, možná bude trošku rozdíl mezi úplnou implementací Bandicoot QT překladem do SQL a mezi přibližnou implementací, která by netrvala na 100% kompatibilitě.

Mimochodem, když už jsme u té jiné syntaxe, nemohu si nevzponemout na http://squeryl.org/ .

...bude narážet na stejné hw limity - což je seq scan a fsync. ...

ano, s tim souhlasim, myslim, ze jste to 100% trefil. To je take ten zasadni problem te myslenky 'relacni', ze totiz uz z principu takove databaze operuji s 10 x vice udaji, nez by byly pro konkretni ulohu potreba. (kdyby se napr. ta sama uloha provadela nad nejakou VSAM databazi).

Tuto velkou nevyhodu relacnich databazi se vyrobci snazi resit ruznymi optimalizatory, je ovsem mozno pozorovat, ze s rostouci komplexnosti uloh rostou i naklady na 'vyrobu optimalniho' provadeciho planu a tam je hranice tech relacnich systemu.

Urcite odlehceni ovsem ocekavam od novych harddisk-technologii.

VSAM databáze také nejsou na všechno. Relační databáze jsou to nejlepší, co tu bylo, pro běžný hw a hromadné zpracování úloh. Nesmíte zapomenout, že seq scan je stále mnohem rychlejší než random IO. Až budou databáze uložené v nějaké variantě persistentní operační paměti, tak je možné, že se vrátíme k síťovému modelu - i když si moc nemyslím - výhodou relačních databází je jejich univerzálnost - tu zatím žádná jiná architektura nepřinesla.

Trocha som sa pohral s Bandicoot a pre Java programatorov som spravil malu knniznicu, ktora mapuje relacie z Bandicoot na Java objekty. Na strankach projektu najdete aj dokumentaciu http://bandicoot.ajka-andrej.com/