Hlavní navigace

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

  • Článek je starý, nové názory již nelze přidávat.
  • 9. 6. 2011 1:09

    VM (neregistrovaný)

    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ů)?

  • 9. 6. 2011 7:38

    bez přezdívky

    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.

  • 9. 6. 2011 9:28

    VM (neregistrovaný)

    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ů.

  • 9. 6. 2011 9:59

    bez přezdívky

    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 :(

  • 9. 6. 2011 11:43

    Tomáš Vondra

    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.

  • 9. 6. 2011 12:05

    Tomáš Vondra

    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

  • 9. 6. 2011 12:25

    jos (neregistrovaný)

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

    já sem si zase při četbě Database in Depth říkal "WTF? proč je to SQL tak hrozný?"

    takže sem rád že se našel někdo, kdo implementuje relační databázi (bandicoot), SQL databáze nejsou relační

    sice si nedělam iluze že by se bandicoot za mýho života probil do korporátní sféry, ale na takové to domácí programování dam bandicootu šanci

  • 9. 6. 2011 14:25

    bez přezdívky

    Cieľom článku je priniesť iný pohľad na relačný model ako sme všetci zvyknutí. Nesnažil som sa povedať, že SQL je nanič a Bandicoot je lepší. Snažím sa ukázať, že sa relačná algebra a model dájú použiť aj pri programovaní a nie len pri modelovaní databáz a dotazovaní.

    Osobne si myslím, že práve neexistencia relačných typov a premenných v SQL je jeho obrovská nevýhoda (napr. neumožňuje vytváranie knižníc, pričom relačný model to plne dovoľuje). Mňa osobne irituje keď niekto tvrdí, že SQL a systémy s týmto jazykom sú relačné a pritom neimplementujú dôležité vlastnosti tohto modelu, ale to je môj názor.

    a teraz k Vašim otázkam:

    1) constrainty sú v pláne a budú podporované aj zložitejšie typy, a nie len primárne/cudzie kľúče, check constrainty, a unikátne kľúče)
    indexy bandicoot už má a sú zabudované transparentne

    2) zložitá otázka, záleží na zložitosti modelu a Vaších očakávaniach na výkon

    3) Bandicoot podporuje kompletné ACID vlastnosti už teraz.

    4) nikde v článku sa nepíše, že optimalizátor nie je potrebný. Píše sa tam, že taký optimalizátor ako ho poznáme v súčastných RDBMS nie je potrebný. Existuje množstvo iných funckií, ktoré može optimalizátor vykonávať.

    5) používanie Bandicootu pre systémy s väčším množstvom používateľom nemusí byť vôbec problém. A práve naopak, pokiaľ chcete mať výkonný systém s veľkým množstvom dotazov budete musieť, s najväčšou pravdepodobnosťou, vykonávať "bulk" operácie -> a znovu relačný model je na toto ako stvorený, keďže pracuje s vždy s množinami. Čo sa týka Bandicootu, tak ten už teraz podporuje "batch scalability" (je to distribuováný systém, kde môžete distribuovať nie len dáta ale pridávať do clusteru aj inštancie, ktoré vykonávajú relačné operácie). Bohužiaľ, "transaction scalability" je stále problém a budem rád ak sa nájdu ľudia, ktorý nám s tým pomôžu :)

  • 9. 6. 2011 15:40

    Tomáš Vondra

    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).

  • 9. 6. 2011 16:21

    bez přezdívky

    ad 1) bohužiaľ nestíhame udržovať našu webovú stránku tak aktuálnu ako by sme chceli :( Odpoveď je áno, indexy sú vytvárané automaticky v prípade operátorov, kde to dáva význam.

    ad 2) pozrite si tento blog http://bandilab.org/blog/2011-02-13.Ostap.Performance_of_the_Bandicoot_v1.html a získate lepšiu predstavu ako rýchlo fungujú jednotlivé operácie. Bandicoot sa nám zatiaľ podarilo nasadiť na dvoch miestach. V prvom rade sú to komentáre na našej stránke samotnej a potom je to malá aplikácia na správu objednávok pre jednu Slovenskú firmu. Objem objednávok v súčasnosti predstavu pár tisíc.

    ad 3) durability je riešená pomocou zápisu premenej do nového súboru a transakcia je potvrdená až keď všetky zmenené globálne premenné sú zapísané na disk. Môžete sa na to pozerať ako na transakční log pre každú premennú samostatne), navyše sa používa jeden súbor na ukladanie informácií o posledných verziách súborov.

    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í)

  • 9. 6. 2011 17:56

    Ivan (neregistrovaný)


    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.

  • 9. 6. 2011 18:29

    bez přezdívky

    Plne s Vami súhlasím čo sa týka optimlaizácie výberu algortimu pre jednotlivé operátory. V tom je práve sila relačného modelu, ten umožňuje zapísať len, ktorý operátor použiť (napr. JOIN), ale už nie ako.

    Problém optimalizátorov je, že potrebujú poznať veľkosti dát, histogramy, a iné štatistiky a to nie len tabuliek, ale aj medzi výsledkov vo výpočte. Pokiaľ je funkčnosť systému závislá od takéhoto optimalizátora, tak sa automaticky ukracujete o situácie, kde tieto informácie nemáte jednoducho ako poznať. Príkladom sú napríklad knižnice, alebo aj používateľmi definované operácie, ktoré operujú len so vstupnými argumenti a programátor môže volať tieto knižnice ako s "veľkými" tak aj s "malými" premennými.

    Každopádne je problematika optimalizátorov veľmi zaujímavá. A myslím si, že Bandicoot sa na tieto veci pozerá trochu inak a to prináša so sebou iné výhody.

  • 9. 6. 2011 22:35

    Tomáš Vondra

    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á.

  • 12. 6. 2011 12:27

    Karel (neregistrovaný)

    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ů.

  • 13. 6. 2011 7:18

    Pavel (neregistrovaný)

    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.

  • 9. 6. 2011 20:26

    Inkvizitor (neregistrovaný)

    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.

  • 9. 6. 2011 22:30

    bez přezdívky

    Áno, v ideálnom svete by som aj ja rád mal optimalizátor, ktorý vykoná moju funkciu vždy optimálne. Realita je však iná. Implementovať takýto optimalizátor je úloha nesmierne náročná. Za príklad si môžete zobrať Oracle a jeho optimalizátor. Len ten samotný má desiatky, ak nie stovky, konfiguračných parametrov a hintov, ktoré možete použiť aby ste ho donútili fungovať tak ako chcete vy. A keď si už konečne nastavíte systém tak ako chcete, po najbližšom upgrade Vám to aj tak bude celé fungovať ináč. A to nehovoríme ešte o tom koľko času a pamäte potrebuje samotný optimalizátor na vybratie tej "správnej" verzie. Osobne považujem, takýto prístup za nesprávny a drahý.

    Namiesto toho, preferujem jednoduchšie systémy. Relačný model poskytuje
    silný vyjadrovací aparát, kde sa nemusím zaoberať detailami (napr. ako vybrať
    záznami z množiny, ktoré spĺňajú istú podmienku) ale sústredím sa na zápis
    algoritmu na vyššej úrovni, kde dokážem:
    a) jednoducho pochopyť postupnosť krokov aj keď som ten algoritmus nenapísal ja, čo pri čiste deklaratívnych jazykoch nie je žiadna prechádzka ružovou záhradou
    b) sa môžem spoľahnúť na to, že tento algoritmus sa vždy vykonáva rovnakým sposobôm, čo mi uľahčí jeho testovanie, či už z pohľadu funckionality alebo výkonu.

    Čo sa týka lokálnych premených, tak tie v princípe nie sú v rozpore s
    distribuovaným systémom. Len ako príklad, si viem predstaviť systém, ktorý
    automaticky vykoná výpočet obsahu dvoch premených paralelne, pokiaľ sú tieto dve premenné nezávislé, napr:

    tmp1 := knihy select(rok > 1990);
    tmp2 := predajcovia select(cena < 100.0);

    Týmto príkladom chcem povedať len to, že lokáklne premené v skutočnosti len uľahčujú akúkoľvek automatickú optimalizáciu; paralelné výpočty, ukladanie medzi výpočtov do pamäte a ich využitie v pri ďalších výpočtov, atď.

  • 9. 6. 2011 23:36

    Inkvizitor (neregistrovaný)

    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.

  • 10. 6. 2011 7:49

    bez přezdívky

    Ako som už napísal, osobne sa radšej vzdám komplikovaného optimalizátoru, ktorý sa snaží pochopiť moje dáta a aj mojú aplikačnú logiku. Namiesto toho chcem mať systém, ktorý dostatočne efektívne implementuje operácie. Vďaka tomu, môžem písať programy, ktorých spávanie je mi vopred známe, napr:

    knihy select(rok > 1990) * predajcovia

    používaním bandicootu viem, že obtiažnosť je zhruba:

    #knihy + #knihy log #knihy + #predajcovia log #knihy

    a tá sa nezmeni, pokiaľ sa nezmení spôsob akým sa implementujú jednotlivé operácie, ktorých je ale našťastie iba malé množstvo.

    Zároveň sa musím priznať, že nechápem čo chcete povedať tým, že paralelizácia sekvenčného kódu v podstate význam. Chcete tým povedať, že nemá význam paralelizovať programy napísané imperatívne ale len tie deklaratívne?

  • 12. 6. 2011 17:44

    Inkvizitor (neregistrovaný)

    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.

  • 9. 6. 2011 23:30

    Tomáš Vondra

    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.

  • 10. 6. 2011 7:28

    bez přezdívky

    Myslím, že túto diskusiu je čoraz ťažšie a ťažšie rozvíjať, najmä z dôvodu, že tento článok len veľmi zľahka popisuje základy jazyka Bandicoot a už vôbec nie systém samotný. Nie je ani zďaleka jasné ako to teda celé funguje.

    Pokúsim sa ale odpovedať na obidve otázky naraz. Mám pocit, ža ani druhý diel článku nebude stačiť na zodpovedanie všetkých otázok v tejto diskusii, čo ma len teší :)

    Bandicoot momentálne používa index pri nasledujúcich operátoroch: join, minus, union, project a summary.

    Existuje len jeden typ indexu a indexy sa nikde neudržujú. Sú vytvorené za chodu pre vykonaním každého z týchto operátorov a to zakaždým, aj keby premenná mala 2 záznamy.
    Ak napríklad nampíšem príkaz kniha project(meno), tak sa vytvorí index nad atribútom meno. Ak napíšem kniha project(titul, rok) tak sa vytvorí index nad atribútmi titul a rok.

  • 10. 6. 2011 8:50

    VM (neregistrovaný)

    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é.

  • 10. 6. 2011 9:17

    bez přezdívky

    Vážení páni,

    nikto nepovedal, že spôsob, ktorý momentálne implementovaný v Bandicoote je ten optimálny :) Projekt je v relatívne nový a problematika je komplexná. V princípe si ale stojím za tým, čo som tu už niekoľko krát povedal:

    Preferujem jednoduché systémy, ktoré fungujú dostatočne efektívne pre moje potreby a, ktorým môžem veriť a predvídať správanie mojich algoritmov. NIe som zástancom komplikovaných optimalizátorov, ktoré sa snažia pochopiť všetko a rozhnodúť za programátora.

    Celá pointa článku a projektu samotného priniesť iný pohľad na relačný model a ukázať, že sa dá implementovať aj ináč ako dotazovací jazyk SQL, a dokonca to prináša výhody.

  • 10. 6. 2011 13:08

    Tomáš Vondra

    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."

  • 10. 6. 2011 14:34

    bez přezdívky

    Vzhaľadom nato, že ide o open-source projekt budem rád ak mu dáte šancu a vyskúšate si ho pri nejakej príležitosti. A ešte radšej budem ak poskytnete aj spätnú vazbu :)

    - kde nie je kritika, tam nie je progres.

  • 12. 6. 2011 12:17

    Karel (neregistrovaný)

    "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.

  • 12. 6. 2011 18:31

    backup (neregistrovaný)

    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.

  • 13. 6. 2011 0:13

    Tomáš Vondra

    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.

  • 13. 6. 2011 8:19

    bez přezdívky

    Bol by som rád keby ste vo svojich príspevkoch neklamali:

    "Snažil jsem se přijít na to pro jaký typ systémů je to vhodnější než tradiční RDBMS, ...., ale když ani autor systému není schopen poskytnout např. nějaké údaje o výkonu pro srovnání, to je pak těžké." -> to nie je pravda. V tejto diskusii ste sa na tieto údaje pýtali a ja som Vám odpovedal, že výkonové testy sú dostupné na blogoch na stránke projektu. Predpokladám, že ste to ani nečítali a znovu sa k tomu vyjadrujete. Ja mám skôr taký pocit, že nie ste schopný prísť na to kde možno takýto systém použiť z jediného dôvodu, t.j. ešte ste Bandicoot nevyskúšali a aj napriek tomu tu naďalej o ňom diskutujete.

    "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." -> ako môžete tvrdiť, že sme nasadili niečo be otestovania si základných výkonnostných parametrov? Buďte si istý, že sme pri nasadzovaní zhodnoditili nie len výkon ale aj iné parametre, ktoré sú často viac dôležité (napr. rýchlosť a zložitosť inštalácie a konfigurácie, náklady na vývoj a intregráciu, správa, atď...)

  • 13. 6. 2011 11:27

    Tomáš Vondra

    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.

  • 13. 6. 2011 12:09

    bez přezdívky

    ad 1) áno v tom máte pravdu, blog hovorí len o benchmarku jednotlivých operácií.

    ad 2) áno je to tak, Bandicoot zamyká celé premenné.

    ad 3) tak ako benchmark tak aj Bandicoot nevolá explicitne fsync/fdatasync. Každopádne miesto v kóde, ktoré je zodpovedné za ukladanie premenných na disk je volume.c a ukladanie stavu transakcií je implementované v transaction.c

    Myslím, že sa zhodneme na tom, že chýbajúce volania fsync/fdatasync je nutné pridať aby bolo potvrdené zapísanie na disk samotný.

    Základné záťažové testy sú dostupné po stiahnutí zdrojových kódov:
    a) test jednotlivých modulov: ./ctl test
    b) test zápisu: ./ctl stress_write
    c) test čítania: ./ctl stress_read

    b) a c) vyžadujú aby bežala inštalácia Bandicoot-u s testovacím programom (test/test_defs.b) na porte 12345. Tieto testy môžete spustiť paralelne v ľubovoľnom počte.

    Je mi jasné, že nie je jednoduché vydolovať všetky potrebné informácie o výkone a porovnať si to s inými systémami. To je daň bohužiaľ za to, že ide o nový projekt, ktorému sa momentálne venujeme len vo voľnom čase.

    A ešte poznámka k tomu klamaniu. Po prečítaní Vášho príspevku to vyznelo ako keby neboli dostupné ani len základné testy ("např. nějaké údaje o výkonu pro srovnání") a navyše sme nasadili do produkcie niečo čo sme ani neotestovali ("a neotestovat si základní výkonnostní parametry"). Jednoducho to nie je pravda, ale vydím to tak, že na tomto sa nezhodneme.

  • 9. 6. 2011 6:43

    djicha

    Určitě je to zajímavý projekt, jen mě napadá k čemu je to dobré? SQL je základ bez kterého se prostě žádný vývojář patrně neobejde. Na trhu je velké množství řešení, které pokryjí valnou většinu potřeb a chybí li něco, tak se téměř vždy bez toho dá obejít.

    Opravdu by mě zajímalo, co tak kritického umí Bandicoot bez čehož by se v PL/SQL, nebo PL/pgSQL nedalo existovat.

    Určitě se těším na pokračování, kde se nad dozvím, jaké je řešení v uživatelském konkurenčím prostředí, kdy je nutné řešit například explicitní zamykání záznamů, nebo dlouhotrvající transakce (uživatelé produktů na kterých pracuji mají rozdělanou operaci v jedné transakci i třeba 14 dní).
    Další je věc která by mě zajímala je, jaké jsou možnosti migrace a hlavně časové nároky.

    Zde se píše http://bandilab.org/specification.html#transactions
    že není nutno psát roollback, ani commit, ale co když chci prostě jen testovat výsledky opravných skriptů apod. a nechci změnu dat natvrdo ukládat?

    Stálo by za to uvést výsledky zátěžových testů, nebo kde je Bandicoot použitý v nějakém produkčním prostředí.

  • 9. 6. 2011 7:50

    bez přezdívky

    Tranzakcie sú spravované automaticky. Pokiaľ chcete zmeniť časť dát, potom čakať nejakú dobu a neskôr sa rozhodnúť či túto zmeniť potvrdiť alebo zrušiť, tak nevidím dôvod prečo s tou zmenou nepočkať a vykonať ju až v momente ked viem, že ju chcem vykonať?

    Systém uzamyká celé premenné, a pokiaľ sa chcete rozhodovať na úrovni záznamov, tak jedine pomocou "optimistic locking". Ak chcete mať funkciu, ktorá len testuje výsledky ale nič neukladá tak jednoducho nazapíšete nič do globálnej premennej, ale o tom už viac v druhej časti :)

    O transakciách aj o základných výkonových testoch sa môžete dočítať na stránke http://bandilab.org/blog.html

  • 9. 6. 2011 8:58

    MD (neregistrovaný)

    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?

  • 9. 6. 2011 9:51

    bez přezdívky

    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.

  • 9. 6. 2011 11:09

    Pavel Prokop (neregistrovaný)

    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?

  • 9. 6. 2011 11:42

    bez přezdívky

    posledná verzia (v3), nepodporuje bohužiaľ constraints. Tie sú na pláne v najbližších verziách (v závislosti od priorít čo ľudia chcú nášho voľného času).

    Je však možné to obísť nasledujúcou funkciou:

    fn Zlava(): Predajca
    {
    # vsetci predajcovia po zlave
    zlava := predajcovia extend(novaCena = cena * 0.5, stav = 1)
    project(meno, titul, novaCena, stav)
    rename(cena = novaCena);

    # mnozina chybnych zaznamov
    chybne := zlava select(cena < 10.0);

    # premenna ok je prazdna ak existuje aspon jeden chybny zaznam
    ok := zlava * (zlava project(meno, stav) - chybne project(stav));

    # novy obsah predajcov je bud povodny obsah predajcov alebo premenna zlava
    predajcovia = predajcovia - zlava project(titul) +
    zlava project(meno, titul, cena);

    return chybne;
    }

    ak by boli constrainty implementovane tak v podstate by sa funkcia zmenila na jedno priradenie, ktore by skontrolovalo contraint. Ale to je blizka buducnost :)

  • 9. 6. 2011 15:05

    Michal Kára (neregistrovaný)

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

  • 9. 6. 2011 17:19

    Michal Kára (neregistrovaný)

    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.

  • 9. 6. 2011 18:00

    bez přezdívky

    Zatiaľ sme tomuto problému nevenovali veľkú pozornosť. Pokúsim sa nad tým zamyslieť a dám Vám vedieť. Vyzerá to tak, že s týmto problémom máte bohaté skúsenosti. Rád sa s Vami podelí o dobré nápady. :)

  • 9. 6. 2011 18:05

    CHe (neregistrovaný)

    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.

  • 9. 6. 2011 18:16

    Michal Kára (neregistrovaný)

    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.)

  • 9. 6. 2011 18:39

    CHe (neregistrovaný)

    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.

  • 9. 6. 2011 20:28

    Michal Kára (neregistrovaný)

    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).

  • 9. 6. 2011 18:46

    bez přezdívky

    Myslím si, že pokiaľ by to išlo vyriešiť priamo v jazkyku bez toho aby sa neporušili jeho princípy a konzistencia tak by to bolo výborné, efektívnejšie, a rýchšie aj z pohľadu vývoja.

  • 9. 6. 2011 22:56

    Tomáš Vondra

    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).

  • 9. 6. 2011 23:58

    CHe (neregistrovaný)

    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).

  • 9. 6. 2011 23:03

    Tomáš Vondra

    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.

  • 10. 6. 2011 9:38

    bez přezdívky

    Čo poviete nato, keby Bandicoot riešil tento problem nasledujúcim spôsobom?

    rel Zamestnanec {
    id: int,
    meno: string,
    manager: int,
    }

    vsetci: Zamestnanec;

    op iteruj(z: Zamestnec, m: rel{manager: int}): Zamestnanec
    {
    if (ids == empty)
    return empty;

    priamy := z * m;
    manageri := priamy project(id) rename(manager = id);

    return priamy + iteruj(z, manageri);
    }

    fn VsetciPodriadeni(n: {meno: string})
    {
    manageri := (vsetci * n) project(id) rename(manager = id);

    return iteruj(vsetci, manageri);
    }

    V riešení používam operátory a inline deklarácie relačných typov, ktoré neboli v článku vysvetlené :(
    Operátory navyše zataiľ nie sú implementované, ale sú na pláne pre najbližšiu verziu.

    Vyzerá to tak, že tento problém je možné vyriešiť, len ak máme ako zapísať cyklus (napr. rekurziou) a podmienky (napr. pomocou if).

  • 9. 6. 2011 23:02

    gbl (neregistrovaný)

    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!

  • 9. 6. 2011 23:11

    vks

    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.

  • 10. 6. 2011 7:12

    bez přezdívky

    Dúfam, že sa mi podarí v druhom dieli článku predstaviť Bandicoot tak, aby bolo tento prínos viditeľný. Ono to totiž celé začína pri forme zápisu, a práve to ako sa to odlišuje od tradičného dotazovacieho jazyka SQL, prináša výhody.

  • 11. 6. 2011 14:37

    Logik

    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".

  • 11. 6. 2011 18:10

    bez přezdívky

    Tato diskusia je dost narocna, pretoze je v clanku popisana len mala cast funkcionality. Vsetky potrebne informacie su ale na stranke projektu, takze mam dve otazky:

    1) Vedeli by ste implementovat optimalizator, s funkciami ake pozname v sucastnych RDBMS, pre jazyk aky pouziva Bandicoot?

    2) Myslite si, ze je principialne mozne prepisat SQL kod do Bandicootu a opacne? Odhliadnuc od toho, ze V Bandicoote este chyba znacne mnozstvo pomocnych funkcii. Nezabudajte aj na to, ze sucastou Bandicootu su aj funkcie, kde je mozne definovat vstupne parametre, ktore su tiez relaciami. Pre jednoduchost sa mozete na ne pozerat ako dalsie operatory algebry definovane pouzivatelom.

  • 13. 6. 2011 15:33

    Logik

    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.

  • 14. 6. 2011 6:40

    Pavel Stěhule

    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.

  • 14. 6. 2011 8:38

    bez přezdívky

    1) len ma zaujímalo či si myslíte, že je to možné. Som rád, že sa zhodneme na tom, že je možné pre tento jazyk implementovať optimalizátor. Mne skôr nebola jasná Vaša formulácia, že za premenné platíme absenciou optimalizátora...

    2) ok, v podstate sa zhodneme na tom, že do čistého SQL to prepísať nejde. Na poskytnutie tej istej funkcionality by sme museli implementovať pojem relačného typu a premennej. Prepísať SQL do Bandicootu ale ide. Z toho usudzujem, že Bandicoot je jazyk so silnejšou vyjadrovacou schopnosťou. Alebo sa mýlim?

    Implementácia Bandicoot jazyka v existujúcich RDBMS by bola skvelá vec. Postupne by sa SQL asi prestal používať :)) Neviazal by som to ale na pojem tabuliek. Jedna z výhod Bandicootu je, že môžete používať relačné typy a funkcie bez globálnych premenných. V takom prípade používate Bandicoot ako výpočtový uzol na rôzne minupulácie so štrukturovanými dátami, bez persistencie a stavu. Môžem teda použiť relačný model a algebru len na implementáciu rôznej logiky bez nutnosti hovoriť o databázach. Vy si myslíte, že niečo také nemá zmysel?

  • 14. 6. 2011 8:43

    Pavel (neregistrovaný)

    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?

  • 14. 6. 2011 8:53

    bez přezdívky

    Nie. Assembler nemá tú istú úroveň abstrakcie ako Bandicoot. SQL a Bandicoot sú jazyky z tej istej domény a poskytujú podobnú úroveň abstrakcie (Bandicoot zrejme o čosi väčšiu keďže sa neviaže na fyzické tabuľky).

  • 14. 6. 2011 10:34

    Vít Šesták (v6ak)

    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.

  • 14. 6. 2011 12:15

    Pavel Stěhule

    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.

  • 14. 6. 2011 12:26

    Vít Šesták (v6ak)

    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.

  • 14. 6. 2011 13:28

    Pavel Stěhule

    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.

  • 14. 6. 2011 13:45

    Vít Šesták (v6ak)

    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/ .

  • 14. 6. 2011 13:24

    jkb (neregistrovaný)

    ...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.

  • 14. 6. 2011 14:11

    Pavel Stěhule

    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.

  • 17. 6. 2011 23:08

    Andrej Petras (neregistrovaný)

    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/