Vlákno názorů k článku Nový pohľad na tradičný relačný model od vks - mi to pripada ze je to jen jina...

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.

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?

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

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

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.