Na počátku všeho byla tabulka

15.9.2018 22:20 | Přečteno: 3998× | poslední úprava: 15.9.2018 22:20

Tuto 'vtipnou' hlášku napsal jeden uživatel ve fóru na root.cz. I když si jistě myslel jak je vtipný, určitě netušil jak blízko je pravdy.

Ve fóru položil někdo otázku, zda mají tabulkové databáze dnes ještě smysl. Samozřejmě se tam objevili zastánci a odpůrci relační technologie a vyměnili si podle mne ty 'obvyklé' názory. A taky jeden ten vtipálek s výše uvedeným bonmotem. Takové reakce se zhusta objevují pod diskuzemi o Excelu, který také nabízí řešení na bázi tabulek. Takoví odpůrci ale nemají nic proti Excelu, většinou je to jen projekce vlastní zášti a neschopnosti na majitele Microsoftu, který vlastní 70 miliard dolarů a tito lidé nemohou jen tak říct, že závidí Billovi ty jeho peníze, tak se opřou do jeho firmy a produktů.

U těch relačních databázi je to něco trochu jiného, zde protestují vesměs lidé, kteří jsou vždycky proti - čemukoliv. Takovým klasickým příkladem je bývalý prezident Klaus. Když jsou všichni pro Evropu, tak on je proti, u změn klimatu podobný postoj a kdyby se ho zeptali, co si myslí o rel. databázích, tak když by se dověděl, že to většina považuje za dobré, tak by na nich určitě něco našel.

Ale zpět k tomu vtipu a proč to vlastně žádný vtip není.

Přesuňme se o několik tisíc let zpátky v historii do oblasti Blízkého východu a severní Afriky. Mlelo se to tam jako dnes a jako vždy v tom hráli hlavní roli Židé. 1700 př.n.l se Židé žijící zhruba již 2000 let na území dnešního Izraele přesunuli do Egypta kvůli hladomoru, který hrozil. Egypt měl tenkrát ty sýpky obilí a lidé mohli přežít. Netrvalo dlouho a Židé se rozrůstali, protože na základě svého náboženství mají menší dětskou úmrtnost (hygiena a odmítání alkoholu). To se domácím Egypťanům nelíbilo a Židy zotročily. 1230 př.n.l se Židé rozhodli emigrovat do své původní země. Vedl je jakýsi Mojžíš, který o tom všem měl napsat knížku, ale novější výzkumy potvrzují, že to napsal někdo jiný. Při tom putování prý Bůh rozevřel Rudé moře a Israelité ho prošli suchou nohou. To je samozřejmě nesmysl, někdo je musel převézt lodí a určitě to nebylo zadarmo. To je dnes to samé, jenom jsou v těch lodích Afričané.

To zásadní se stalo, když dorazili k Sinajskému pohoří. Mojžíš byl velmi chytrý vůdce a věděl, že další budoucnost jeho národa je možné zajstit jen za pomoci jasných pravidel, zákonů. Ale také věděl, že nemůze jen tak předstoupit před národ a sdělit jim, podle čeho se budou řídit. Pro takové situace je třeba se opřít o nějakou autoritu, která by navíc měla být jaksi nedosažitelná - to má tu výhodu, že se té autority nemůže nikdo na nic přímo zeptat. Tuto fintu používáme my běžní lidé také, když napr. 15-letému synovi nedáme klíče od auta s tím, že to zákon nepovoluje. Takové autority se mladý hoch jen ztěžka může zeptat, jestli by to přece jen nešlo. Nebo když se nás 13-letá dcera ptá, zda smí přespat u spolužačky (my všichni víme co se za tím skrývá), tak jí to zakazujeme za pomocui té nejvyšší autority - 'co by na to řekli lidi'.

Mojžíš to udělal podobně a sdělil národu, že ta pravidla mu předal sám Bůh na takových kamených destičkách. Dnes víme, že to nebyl Bůh, ale Mojžíš si to napsal sám, ale stejně je pozoruhodné, jak to stihnul, vyběhnout nahoru, vyrýt ta přikázání a zase seběhnout dolů. A ti bystřejší čtenáři již tuší - ano takové destičce říkáme také tabulka.

Na počátku naší civilizace byla skutečně tabulka.

Ale není to jen ta výrazová shoda. Ta přikázání, která Mojžíš lidu sdělil mají i tu formu jak ji dnes známe. Ta tabulka má dva sloupce, v prvním je primary key (int) a v druhém sloupci je text, který není nějak zvlášť dlouhý tedy char, varchar nebo text podle toho, jakou databázi vezmeme. Je to pozoruhodné, ale relační tabulky jsou s námi na téhle zeměkouli již přes 3200 let. To má svůj důvod - je to přirozené, pochopitelné - někdo by řekl - skoro jako od Boha - a ono to od něj skutečně je.

V novodobých dějinách informatiky došlo zpočátku k iritacím a vznikly nerelační databáze (hierarchické a síťové), ale zhruba po 10 letech se lidstvo vzpamatovalo a znovuobjevilo ten prastarý princip, který se samozřejmě prosadil a dnes je svět plný relačních databázi. Jak výše uvedeno, jsou ale lidé, kteří jsou vždycky proti. Na různých fórech se pak snaží panu Stěhulemu vysvětlit, jaké mají prý relační databáze chyby a jak to nefunguje. Všimněte si prosím, že pan Stěhule dokázal zatím vždy takovou argumentaci vyvrátit. Protože relační databáze fungují. A Excel také. Máme je od Boha.

Dovolte mi jako za starých času (kdy stálo pivo 1.70 Kč) prohlásit:

Sláva relačním databázím!

Sláva uloženým procedúrám!

Ať žijí a vzkvétají deklarativní dotazovací jazyky!

Smrt programatorům, kteří směřují dotazy aplikace přímo do logické vrstvy databáze.

       

Komentáře

[xvasek]

Relační databáze je celkem rozumný kompromis, pokud se člověku nechce vymýšlet a psát něco vlastního, nebo pokud se mu to nevyplatí. Podle mého je dále celkem škoda, že se povětšinou jedná o databáze obsluhované jazykem SQL a že se málo prosazují alternativní metodiky. Vytváření SQL kódu v programu mi přijde jako zvěrstvo, podle mého by měl programovací aparát sám svými konstrukcemi zpracovávat data, ne si k tomu mastit nějaké stringy, které mohou dělat kdo ví co.

K tomuto svému přesvědčení jsem došel po asi pěti letech práce s SQL-based systémy a následně přechodu na systém, který má ten luxus mít vlastní (nerelační) databázi na míru. (Ale který se s relačními databázemi samozřejmě propojuje, takže v SQL jsem do jisté míry pořád.)

[Odin]

Aplikaci, ktera si sama masti stringy, je dobre nevyvijet, zavrhnout a vyhodit. Dneska se to, vazeny pane, dela trochu jinak.

[xvasek]

Ano, umastí se nějaká mezivrstva, která mastí ty SQL stringy. A pak se všichni tváří, že nikdo žádné SQL stringy nemastí. (Samozřejmě čest výjimkám, nebo aspoň lidem, kteří o tom přemýšlí.)

Pokud se to někam pohnulo, rád si nechám doporučit nějaké čtení. To není trolling, fakt mě to zajímá, ještě z doby, kdy jsem si chtěl udělt nějaký vlastní noSQL datový ukládátor.

[kralyk z abclinuxu]

Ano, umastí se nějaká mezivrstva, která mastí ty SQL stringy. A pak se všichni tváří, že nikdo žádné SQL stringy nemastí.

Takhle ale přece fungují všechny komunikační protokoly. Browser mastí HTTP requesty. Jakákoli síťová aplikace mastí TCP packety, UDP datagramy a podobně.

Jde o to mastit je správně.

[johnyK]

OP napsal uplne nahore:

že se povětšinou jedná o databáze obsluhované jazykem SQL a že se málo prosazují alternativní metodiky.

ja si myslim, ze mu prave o tohle jde..

U databazi, ktere pouzivaji SQl se musi ten string 'nekde' vytvorit - bez toho to proste nejde. Kdyby ty databazen nabizely alternativni metodu by sice byly asi nejake jine nevyhody, ale ty stringy by se skutecne nemusely 'mastit'.

[kralyk z abclinuxu]

Kdyby ty databazen nabizely alternativni metodu by sice byly asi nejake jine nevyhody, ale ty stringy by se skutecne nemusely 'mastit'.

No tak by se nemusely mastit stringy, ale mastilo by se něco jinýho. Třeba mongo mastí BSON. V čem je to tak zásadně lepší?

[Käyttäjä 11133]

Třeba mongo mastí BSON. V čem je to tak zásadně lepší?

Není to SQL... /s

[xvasek]

Má to větší tah na bránu. Pokud je maštění SQL v zásadě špatné, pak můžeme: a) dodávat databáze s SQL only frontendem a říct všem, že to vlastně takto nemají používat a mají si napsat / najít nějaký udělátor, aby ten frontend používat nemuseli, nebo b) dodávat databáze, které samy poskytují rovnou _ten správný_ přístup. (Ať už je to cokoli.)

[okbob]

Můžete mi vysvětlit, proč je maštění SQL v zásadě špatně? A maštění v JSONu nebo Javascriptu nikoliv? Přiznám se, že tomu odporu proti SQL vůbec nerozumím. Přijde mi to jako dětinská umanutost.

[xvasek]

Jak se to vezme. Já chci dělat něco jako:

nahraj a zablokuj objekt xy (z tabulky ff) pro úpravy
je hodnota xy.reference_na_záznam_v_jiné_tabulce.něco kladná?
nastav xy.něco na hodnotu "xxx"
ulož xy

Představoval bych si to tak, že zadám aptitude "install databaze connector_k_memu_jazyku" a rovnou bych něco takového mohl psát. Protože proč ne? Pro takové věci je SQL hrozně neohrabaný jazyk a ty nadstavby (mastiče) jsou sice jistým krokem dopředu, ale podle mě by něco takového měla umět už ta samotná databáze, abych se nemusel spoléhat na nějaký toolkit třetí strany, který za půl roku zdechne.

[trekker.dk]

No, zas tak strašlivě složité to není.

update ff set ff.něco = xxx from jina where ff.id=xy and ff.jina_id = jina.id and jina.něco > 0

A určitě by to šlo rozepsat i na 4 řádky

[johnyK]

ja si myslim, ze zde porad dochazi k nejakemu nedorozumneni.

Pan kolega rika, ze by chtel k tomu velmi rozsirenemu deklarativnimu pristupu jeste nejaky jiny a v prikladu nastinil nejaky takovy proceduralni. A ty mu na to odpovidas:

'podivej, ten relacni prece funguje'

[xvasek]

Hm, tak si to po sobě čtu a samozřejmě jsem to napsal pěkně nesrozumitelně. Mezi každé dva řádky si dej tři tečky, které mají znamenat "...spousta věcí se mezitím stane", což simuluje lidského uživatele, který se systémem mezitím interaguje a své chování přizpůsobuje výstupům ze systému.

[FAtbluNT]

Tenhle pristup vypada cool, ale moc neskaluje. Podobne funguje souborovy system, proc tedy nepouzit ten? Se zamykanim prichazi deadlocky, kterych v takove koncepci bude plno a projevi se az kdyz bude uzivatelu vic. Dalsi problemy se projevi s rustem poctu radku.

Ja se klidne priznam ze mam SQL rad, a mimo jine prave kvuli tem stringum. Vezmu string z logu, zoptimalizuju ho na konzoli a kdyz pouzivam vhodny "mastic" typu mybatis tak ho zas vezmu a za par okamziku ho flaknu zpatky do aplikace. Zadny lepeni, zadny premysleni kam co a kdy patri, zadny prepisovani do necitelnyho orm-like proceduralniho kodu plnyho ifu. Rozhrani je nemenny, operace atomicky.

[xvasek]

Ano, zámky a škálování jsou "problém" tohto přístupu, ale na druhou stranu mi přijde, že řešením tohoto problému řešíš nějakou reálnou situaci: Opravdu potřebuju, aby dva lidi měnili jednu fakturu zaráz? Není opravdu lepší tomu druhému říct, že má přijít později, než vymýšlet protokol, pod kterým to zvládnou?

Mně třeba zase přijde, že právěže vytahování SQL stringů z logu a jejich simulace (na stále se měnících datech) je jedna z věcí, o kterou jsem sice bez SQL "přišel", ale - teď se všem, kteří mají v této činnosti zalíbení, omlouvám - to pro mě byla asi nejhnusnější část toho, co jsem kdy s SQL systémy dělal.

[FAtbluNT]

Opravdu potřebuju, aby dva lidi měnili jednu fakturu zaráz?

A co kdyz nad tou fakturou (potazmo nad vsemi) bezi analyticky dotaz v pravidelnych intervalech? Co kdyz se ke kodu dostane nekdo (kolega junior) kdo zamkne tu fakturu a nasledne vyhodi vyjimku, neosetri to a zaznam zustane zamceny naveky? Nebo vypadne spojeni? On ten pristup "odesli prikaz a zapomen" ma sve vyhody - nekdy clovek zasne co ta DB musi od uzivatelu vydrzet.

Ta "simulace" - optimalizace dotazu v konzoli - je to co clovek dela ve chvili kdy a) stavim aplikaci od nuly a prvne si timhle REPL-stylem utridim myslenky na to jak jsou data v DB ulozena, b) narostlo mnozstvi dat (radove) natolik ze puvodni dotaz prestal stacit nebo c) doslo ke zmenam ve strukture DB z duvodu ad b) a nebo z jinych duvodu.

Je to dan za to,ze spoustu te prace ta DB oddre za aplikaci. Vyresi propojeni dat z ruznych tabulek, seskupeni, razeni, predpocita vysledky a doda je v temer hotove podobe - staci je jen prevzit a zobrazit. Proto to taky jde vyzkouset "rucne" na te konzoli. Mozna to povazujes za hnus, mozna je SQL pro tebe prilis "alien-like" ale ja radeji necham svou aplikaci okamzik cekat na rozhranim velmi citelne definovany dotaz (ktery mi BTW muze optimalizovat i kolega databazista) a ja se o nej nebudu starat, nez si tu optimalizaci (ktera se skalovanim bude stejne nutna) oddrit v app a zurit nad mnozstvim chaosu, ktere tim vytvorim.

[xvasek]

Lidi, málo přemýšlíte, moc píšete. Zavedu readlock a writelock a je to hotové, pak analytický (read) dotaz sběhne i nad zamčenými záznamy. Pokud spadne spojení, tak se provede roolback a otevření všech tím spojením zamčených objektů.

[FAtbluNT]

Takze na nestabilni siti se to bude porad odemykat protoze mezi operaci zamceni a upravou zaznamu se ceka na interakci...

[johnyK]

ktery mi BTW muze optimalizovat i kolega databazista) a ja se o nej nebudu starat,

chtel bych upozornit , ze ne kazdy muze pracovat v takove firme, kde ma programator k ruce databazistu, ktery optimalizuje jim stvorene dotazy. U velkych korporatu to mozna jde, ale u mensi firmy jsem to jeste nevidel.

[FAtbluNT]

No jasne, netvrdim ze je to samozrejmost. Ale minimalne je to oddelene - takze treba alespon se zkusenejsim kolegou muze clovek mrknout na ten dotaz separatne a pak jej opraveny/optimalizovany vratit do aplikace. Dukaz ze to funguje jak ma se da udelat pouhym spustenim toho SQL v konzoli.

Dalsi vyhoda je ze se meni jen jedna vrstva, a vsechny veci nad tim zustanou nemenne, a to i v pripade nejakeho brutalnejsiho refaktorovani DB (kdy se tabulky tristi, sloupce prehazuji sem tam a data jakbysmet).

[okbob]

Ona většina optimalizací spočívá v kontrole indexů, odhadů. Běžný vývojář může udělat 70% toho co expert. Výhoda zkušeností je v citu na rozpoznání, že je něco špatně. Běžný vývojář narazí na pomalý dotaz, a začne uvažovat o clusteringu, NoSQL a masivní paralelizaci. Zkušenější vývojář se podívá na prováděcí plány, případně statistiky a zkontroluje jestli nevyhnívají indexy nebo nejsou latence na disku. Teprve potom začne řešit cluster a horizontální škálování.

V podstatě jsem nenarazil na zákazníka, kterému by problémy nevyřešilo několik málo indexů - u OLTP databází. A to fakt není žádná magie. Něco jiného je, když se dostáváte nad terabajty - docela jsem se divil, když jsem u jednoho zákazníka viděl 30TB tabulku. Nebo, když se dostáváte nad 10K dotazů za sec. Tam už je pak horizontální škálování nutnost.

[okbob]

V SQL to vše vyřeším jedním jednoduchým UPDATEm, a nemusím nic zamykat nebo něco ukládat.

Proč by databáze měla umět tak neohrabaný jazyk, který tu popisujete - navíc v které variaci, pro C, C++, Javu, ...

[xixao]

Tohle by asi šlo, ne? B-)

DECLARE
  CURSOR c_blokator IS
    SELECT ... FROM tabulka FOR UPDATE NOWAIT;
  v_blokator c_blokator%ROWTYPE;
BEGIN
  OPEN c_blokator;
  FETCH c_blokator INTO v_blokator;
  IF c_blokator%FOUND THEN
    IF ... THEN
       UPDATE ... WHERE CURRENT OF c_blokator;
    END IF;
  END IF;
  CLOSE c_blokator;
  COMMIT;
END;

[xixao]

pozn.: v PL/SQL jsem to psal schválně, jde to (jak píšou jiní) jedním UPDATEm

[xkucf03]

+1

Ono sice i to SQL má svoje slabší stránky a někteří relační puristé ho odmítají, ale většina běžné kritiky SQL téhle úrovně argumentace vůbec nedosahuje (ti lidé obvykle neznají teorii za relacemi/SQL, ani teorii za tím údajně lepším řešením, a jen do toho promítají nějaké vlastní křivdy, neúspěchy a nepochopení).

Velkou výhodou těch "umaštěných SQL stringů" je mj. to, že nejsou spjaté s danou aplikací ani nějakým nástrojem a lze je spouštět odkudkoli. Takže jde vzít část aplikace (SELECT) a ladit ji ručně nebo ji použít pro získání dat v jiném nástroji. Je to podobná transparentnost jako u textových souborových formátů. Sice to není absolutní argument proti těm binárním, ale určitou výhodu ta textovost/transparentnost představuje.

BTW: co říkáte na GraphQL? Kdyby to nebyla hromada javascriptových hoven a mělo to nativní podporu třeba v PostgreSQL, tak by mi to přišlo docela dobré :-)

[johnyK]

ti lidé obvykle neznají teorii za relacemi/SQL, ani teorii za tím údajně lepším řešením, a jen do toho promítají nějaké vlastní křivdy, neúspěchy a nepochopení

1. RDBMS Are Not Designed To Handle Change
2. RDBMS Are Not Designed for Heterogeneous Data
3. RDBMS Are Not Designed For Scale
4. RDBMS Are Not Designed for Mixed Workloads
5. RDBMS Are A Mismatch for Modern App Development

[kralyk z abclinuxu]

Budu hádat: Ta firma se živí NoSQL.

[kralyk z abclinuxu]

Tak jsem se na to podíval blíže a to je takovej PR bullshit, až to ani není moc vtipný...

[xkucf03]

Od autorů nějakého DBMS to může být relevantní (byť subjektivní) kritika.¹ Ta moje poznámka se týkala spíš lidí, kteří se navážejí do SQL, protože s ním nebyli úspěšní -- což ovšem neznamená, že budou úspěšní s jinou technologií/paradigmatem. Velká část z nich právě ne a navážejí se prostě jen do technologie, se kterou přišli poprvé do styku. Kdyby dělali s dokumentovou nebo grafovou databází, tak by nadávali na ně.

SQL je nejrozšířenější, a proto existuje i nejvíce kritiků tohoto druhu, kteří kritizují SQL.

_{[1] Sám taky občas narážím na jeho limity nebo na věci, které se v něm dělají ne zrovna hezky -- a přesto považuji SQL/RDBMS za velmi užitečný nástroj a pro mnoho úloh ten nejlepší.}

[johnyK]

samozrejme, ze mas pravdu v tom, ze kdyz je neco rozsirene, tak bude take hodne kritiku. A rada argumentu z tohoto smeru bude jiz statisticky irelevantni.

Vseobecne si ale myslim, ze napr. ta myslenka , ze to RDBMS/SQL paradigma neni vhodne, kdyz se musi casto neco mnenit, je opravnena kritika. A ta kritika se da odvodit z toho paradigmatu samotneho - totiz, ze se nejdrive daji hlavy dohromady, vymysli se schema na zaklade aktualnich informaci, pritom se neustale musi myslet na ty pozdejsi SQL-prikazy , aby to behalo dost rychle a pak se napise ta aplikace - nejlepe za pomoci ulozenych procedur. V praxi to tak vlastne probiha - nebo by melo, ne?

A pak prijdou ty zmeny. Protoze ten zadavatel neco zapomnel, ten analytik to blbe pochopil a nebo se zmenily ty okolni podminky.

To co ten pan popisuje mi prijde smysluplne a jestlize nabizi nejaky system, ktery timto netrpi tak je prece spravne, ze na to upozornuje. To neni podle mne jen nejaky PR.

[JS1]

A u modelovani pomoci typu ti ta zmena nevadi? Nebo jsi tvrdy zastance dynamicky typovanych jazyku?

Ja vidim existenci schematu asi stejne praktickou jako existenci typu v programu.

[johnyK]

tvrdy zastance dynamicky typovanych jazyku?

ja jsem tvrdym zastancem silne staticky typovanych jazyku - tedy fortranu, kdy uz ze jmena promene je jasne , o jaky typ se jedna. Proto take v perlu, kdyz pisu $i,$j,$k..$n , tak to jsou pro mne vzdy integer.

Tvoje poznamka je ale dobra. Pokud se v nejakem navrhu rozhodnu stritktne typovat a pak se zjisti, ze misto int je potreba double, tak pak event. nebudu vedet, kde mam vsude v programu menit. A jestli se v tech RDBMS/SQL systemech pouzije schema, ktere je navic silne svazano s tim dotazovacim mechanismem, tak potom se nelze divit, ze zmeny budou bolestive. Ja se nedivim, ze ti NoSQL fandove jako prvni rekli, ze schema neni dobre.

Ale tim jsme skoro uz u te odpovedi uzivateli xvasek, proc jeho touha po jinem dotazovacim zpusobu v RDBMS nez SQL nemuze byt uspokojena. Ale uplne zduvodneni by mu meli presto predlozit ti pritomni SQL-evangeliste.

[kralyk z abclinuxu]

To co ten pan popisuje mi prijde smysluplne a jestlize nabizi nejaky system, ktery timto netrpi tak je prece spravne, ze na to upozornuje. To neni podle mne jen nejaky PR.

Mně jako PR přišla ta kritika, kde tvrdí, že RDBMS neškáluje a že 80% dat je nestrukturovaných, tudíž na to RDMBS je špatná. Přitom v praxi RDMBS kolikrát výkonem a škálováním nakopávají zadek NoSQL. Zejména ty grafy a demonstrace strukturovanosti dat na nějakém GUI mi přijdou jako naprostý BS.

Vseobecne si ale myslim, ze napr. ta myslenka , ze to RDBMS/SQL paradigma neni vhodne, kdyz se musi casto neco mnenit, je opravnena kritika.

S tím souhlasim. Na druhou stranu třeba PostgreSQL podporuje dynamická / schema-less data svými typy HSTORE, JSON a JSONB, tj. v zásadě můžeš mít část data relačně a část dynamicky nebo mezi nimi nějakým způsobem přecházet.

[kralyk z abclinuxu]

a) dodávat databáze s SQL only frontendem a říct všem, že to vlastně takto nemají používat a mají si napsat / najít nějaký udělátor, aby ten frontend používat nemuseli, nebo b) dodávat databáze, které samy poskytují rovnou _ten správný_ přístup. (Ať už je to cokoli.)

Za mě je mnohem lepší to a), protože si můžu zvolit ten udělátor a tím pádem i ty parametry toho přístupu sám podle toho, jaké jsou požadavky/nároky mé aplikace. Zatímco v tom b) by mi byl nanucen TenSprávný™ přístup bez možnosti volby. Nerozumim, v čem by to mělo být lepší.

[xvasek]

Diskuse je víceméně o tom, jestli pouze SQL - jak je současný stav světa - je TenSprávný™ přístup.

Já nejsem apriori proti SQL, ať tam klidně je. Ale ať má člověk možnost si zvolit z co-já-vím pěti různých paradigmat rovnou od výrobce databáze, protože těch objevujících se a umírajících knihoven tohoto typu je prostě příliš moc na to, aby člověk s některou spojil svou budoucnost. Pak to končí tak, že si to firma raději napíše sama a jsme tam, kde jsme byli.

[deda.jabko]

Ale ať má člověk možnost si zvolit z co-já-vím pěti různých paradigmat rovnou od výrobce databáze

Tento pozadavek je od zacatku uplne zcestny. Relacni (SQL) databaze maji sve vlastni paradigma, kterym je relacni model. Pokud budes chtit databazi ovladat dle jineho paradigmatu, prijdes o vetsinu tech hezkych vlastnosti, jako je treba optimalizace dotazu a degradujes tak databazovy system na uplne obycejne skladiste hodnot, pravdepodobne nejaky key-value store. (Coz teda rada lidi dela a neprijde jim to divne.)

Ale dobre, pokud ti nevyhovuje SQL a relacni DB, nebylo by lepsi na ne zapomenout a pouzit rovnou nejaky key-value store ala BerkeleyDB, ktere jsou na to primo stavene?

[johnyK]

Tento pozadavek je od zacatku uplne zcestny

no, nekolik takovych 'relacnich' databazi jeste myslim existuje. Napr. SAP Advantage Database Server.

prijdes o vetsinu tech hezkych vlastnosti, jako je treba optimalizace dotazu

ale ta optimalizace je tam prece jenom proto, ze by jinak to relacni paradigma smysluplne nefungovalo. U jinych paradigmat ta optimalizace neni vubec potreba.

[Josef Kufner]

U key-value úložiště ty operace vůbec neuděláš a musíš si je celé naprogramovat v aplikaci. Relační databáze toho umí spoustu a pokud nad ně nedáš tupé ORM, tak dokážou hodně zjednodušit logiku postavenou nad nimi. O pár komentářů výše je docela hezký příklad, kdy aplikace jen pošle do databáze příkaz a už nemusí řešit zamykání a další technické detaily kolem.

[xvasek]

Jenomže zrovna ten příklad byl blbě napsaný (a pochopený). Udělám to znovu.

(čekej na interakci uživatele)
nahraj a zablokuj objekt xy (z tabulky ff) pro úpravy
(čekej na interakci uživatele)
je hodnota xy.reference_na_záznam_v_jiné_tabulce.něco kladná?
(čekej na interakci uživatele)
nastav xy.něco na hodnotu "xxx"
(čekej na interakci uživatele)
ulož xy
(čekej na interakci uživatele)

(Rozhodně neříkám, že to v SQL nejde.)

[deda.jabko]

To, co hledas, se jmenuje FoxPro.

nahraj a zablokuj objekt xy (z tabulky ff) pro úpravy (čekej na interakci uživatele)

A z tohoto te driv nebo pozdeji bude dobre bolet hlava. Neni nic lepsiho, kdyz jeden clovek zamkne nejaky zaznam u rozdelane prace (jde na obed, domu) a zbytek oddeleni nemuze pracovat, protoze ten zaznam blokuje nejakou dalsi operaci, kterou oni potrebuji.

[xvasek]

Tak bez ohledu na to, jak směšné označení tomu dáš, u takového systému stejně časem nějaký zamykací mechanismus mít musíš. Nakonec ti zůstanou politiky "beru změny od prvního", "beru změny od posledního" a "záznam je zamčený". Pak už je to na tobě, abys zamykal jenom to, co je potřeba, abys nezasekal celé oddělní.

[kralyk z abclinuxu]

Mně ten příklad přijde ortogonální k diskusi, přijde mi, že spíš řešíš logiku aplikace než SQL/NoSQL ...

[xvasek]

Ano, chci řešit aplikační logiku, ne SQL. Asi jsem neměl příležitost pracovat se systémy, které mají toto dostatečně oddělené, abych věřil tomu, že jde řešit aplikační logiku jinak, než víceméně v SQL, i když se to pak třeba obalí třeba něčím jiným.

[deda.jabko]

Tak bez ohledu na to, jak směšné označení tomu dáš

Nechapu. Jake smesne oznaceni?

Pak už je to na tobě, abys zamykal jenom to, co je potřeba, abys nezasekal celé oddělní.

Pokud das mezi "zamknu zaznam" a "ulozim zmeny a odemknu " libovolnou interakci s uzivatelem, je to prusvih. Delal jsem N-let na informacnich systemech ve FoxPro, kde se programovalo presne timto zpusobem a tyto problemy byly na dennim poradku.

Je paradoxni, ze v beznych programovacich jazycich se lidi snazi zbavit zamku, jak to jen jde, protoze zamky predstavuji neskonale mnozstvi prilezitosti, jak je pouzit blbe, a hlavne zamky brani skalovani. V kontextu tohoto problemu se databazove systemy davaji za vzor toho, jak s minimem namahy (s pomoci transakci) lze vytvorit system bezproblemu zvladajici stovky/tisice soubeznych pozadavku menicich data.

[xvasek]

Jak problém jedné faktury editované dvěma uživateli řeší moderní systémy současného tisíciletí?

[deda.jabko]

Moderni systemy tento problem per se neresi, protoze to, co chces resit ty, neni problem ulozeni dat, ale aplikacni logiky, kdy soucasti specifikace musi byt, co se ma v takove situaci stat.

Tvuj navrh se zamykanim zaznamu navic nebude fungovat. Dejme tomu, ze mas dve tabulky "faktura" a "polozky_faktury", kdyz si zamknes zaznam pro tu konkretni fakturu, porad mohou dva uzivatele soubezne editovat polozky. Dobre, tak si zamknes i existujici polozky prislusne faktury. No, ale i tak dva uzivatele budou moci soubezne fakturu zmenit vlozenim dalsich polozek. Co s tim?

Jinak pristup zalozeny na zamykani je prilis pesimisticky a docela neprakticky. Proto se (vcetne ruznych dokumentovych databazi) radeji voli optimistictejsi pristup, kdy kolize resis az kdyz nastanou. Typicky tak, ze objekt/dokument ma nejakou verzi/timestamp a pred commitem sledujes, jestli nedoslo ke kolizi a nekdo uz neprovedl zmenu. Az pokud skutecne doslo ke kolizi, zacnes to resit.

[Bherzet]

Příkladem dokumentové „databáze“, která používá optimistickou strategii, o které se zmiňuješ, je Elasticsearch (jeho roli vidím trochu jinak než u konvenční databáze, proto uvozovky).

[xkucf03]

+1

[xvasek]

To je deformace myšlení přes RDBS. Pokud je faktura definována jako objekt včetně řádků, tak jde zamykat v pohodě i proti přidávání / mazání řádků.

Jinak navrhuješ strategii "poslední má pravdu". S takovým systémem jsem dělal a z pohledu uživatele děsně napřesdržku. Uživatel dělá na nějakém reportu půl hodiny, pak to chce uložit a systém mu řekne, že jej mezitím změnil někdo jiný. Chápu, že z pohledu technické podpory je to čisté řešení, ale z pohledu toho uživatele dost nepraktické. Nebylo by lepší mu před tou půlhodinou říct, že na stejném reportu právě dělá Máňa a ať se spolu domluví?

Zamykáním není pesimistický přístup. Řeší konflikt přesně ve chvíli, kdy nastane, ne půl hodiny později.

Samozřejmě jsou systémy, pro které je vhodnější nezymkací přístup a jsou systémy, kde je vhodnější zamykat. Třeba u ERP mi přijde nezamykání o hodně horší strategie z pohledu uživatele.

[Bherzet]

Jinak navrhuješ strategii "poslední má pravdu". S takovým systémem jsem dělal a z pohledu uživatele děsně napřesdržku. Uživatel dělá na nějakém reportu půl hodiny, pak to chce uložit a systém mu řekne, že jej mezitím změnil někdo jiný. Chápu, že z pohledu technické podpory je to čisté řešení, ale z pohledu toho uživatele dost nepraktické. Nebylo by lepší mu před tou půlhodinou říct, že na stejném reportu právě dělá Máňa a ať se spolu domluví?

To je problém, který bych řešil na úplně jiné úrovni než je nějaké zamykání položek v databázi.

[Bherzet]

(A není to „poslední má pravdu“, ale „první má pravdu“.)

[xvasek]

Proč bys to řešil na jiné úrovni? (Podle mě je odpověď "protože se to na úrovni RDBS dělá blbě", ale jsem zvědavý na jiné vysvětlení.)

[kralyk z abclinuxu]

Podle mě je odpověď "protože se to na úrovni RDBS dělá blbě", ale jsem zvědavý na jiné vysvětlení.

A s NoSQL se to dělá lépe? Nevim o tom, že by tohle nějak moc řešilo... Jinak IMHO tohle odpověď není.

Moje 2 centy: Je to rozdělení zodpovědností/kompetencí, ie. dělá se to ze stejného důvodu jako se kód programů dělí na struktury, třídy, moduly atd., případně rozdělení na backend a frontend atp., tzn. každá část se stará o svoji jasně vymezenou doménu odpovědnosti. Ta idea je, že persistenční vrstva se stará o persistenci dat a aplikační o interakci s uživatelem. Jasně, můžeš mít všechno na jedný hromadě, databáze, co si povídá s uživatelem, špagetovej kód atd., ono to taky jde, ale bude to nepřehledný a hůř udržovatelný...

[deda.jabko]

Plny souhlas. Tecka.

[xvasek]

U systému, se kterým pracuji, se o interakci s uživatelem stará GUI, o persistenci aplikační server a o data databázový stroj, to není nic divného. Jenom mají prostě trochu jinak rozdělené kompetence, než je obvyklé. Špagetový kód tam nevzniká, udržovatelné mi to přijde velmi dobře - už skoro čtyřicátým rokem. Udělali to kluci od začátku modulárně, takže se nikdy nedostali do situce "musíme to celé přepsat".

V kontextu této diskuse mi každopádně přijde celkem zajímavé to přesvědčení, že zrovna takto se to má dělat: SQL databáze - SQL mastič - aplikační server - GUI a že to rozdělení kompetencí je prostě dané, nejlepší možné a nemá absolutně cenu hledat něco lepšího. Trochu jsem čekal víc lidí jako Jardík, který si maže kořenové autority z Firefoxu, protože mu tento jinak obecně přijímaný mechanismus nepřijde správný.

[kralyk z abclinuxu]

Já jsem tu fázi nadšení z NoSQL před pár lety absolvoval, ale byl jsem ve výsledku zklamán a radši jsem se naučil něco víc o SQL/RDBMS, hlavně Postgres ... (Ačkoli na to ani tak nejsem žádný guru a akutálně už to nedělám vůebc ...)

V kontextu této diskuse mi každopádně přijde celkem zajímavé to přesvědčení, že zrovna takto se to má dělat: SQL databáze - SQL mastič - aplikační server - GUI a že to rozdělení kompetencí je prostě dané, nejlepší možné a nemá absolutně cenu hledat něco lepšího.

Mně zas přijde celkem zajímavé to přesvědčení, že SQL/RDBMS je špatně a to setrvalé používání hanlivých výrazů bez schopnosti vysvětlit, co je teda vlastně na tom špatně...

[xvasek]

To jsem nikde nepsal. Klidně to tady napíšu znovu - SQL je výborné řešení pro určitě většnu případů, kde se používá. To mu přesto nedává patent na to být nejlepší architekturou vždy a všude.

[kralyk z abclinuxu]

Tak s tím souhlasím, mně třeba přijde zajímavé GraphQL a grafové databáze. (Tím zklamáním z NoSQL jsem myslel hlavně MongoDB.)

[Josef Kufner]

A zrovna GraphQL a relační databáze toho mají společného velmi mnoho. Copak asi ta hrana v grafech schovaných za GraphQL znamená?

[JS1]

Uz jsem to psal na Root - taky se mi to plete - GraphQL neni o grafovych databazich, to co chces je SPARQL.

[kralyk z abclinuxu]

Já neříkal, že GraphQL je o grafových databázích, vím, že není, myslel jsem to tak, že obojí mi přijde zajímavé (i když to spolu nutně nesouvisí).

[JS1]

Aha, OK. IMHO GraphQL je naprosto nevhodny nazev.

[Bherzet]

Protože je to znásilnění databáze k něčemu jinému než na co je určena.

[Odin]

To, co chcete vy, se na urovni relacni databaze neresi. Za hloupou aplikaci databaze nemuze. Databaze je naopak chytra a diky referencni integrite muze zajistit konzistentni data, i kdyz je databaze hloupe navrzena a pro uzivatele nekomfortni.

[deda.jabko]

To je deformace myšlení přes RDBS. Pokud je faktura definována jako objekt včetně řádků, tak jde zamykat v pohodě i proti přidávání / mazání řádků.

Pokud chces s daty pracovat jako s objekty (vcetne jejich provazani) a pouzivat zamykani, tak ti preju hodne stesti. V programovacich jazycich se toho lidi snazi zbavit, protoze jsou s tim jenom mrzeni -- zamknes toho moc, neco prestane fungovat, zamknes toho malo -- bude mit nekonzistentni data, zamknes to v blbem poradi -- mas deadlock... spousta mist, kde se da udelat chyba.

Jinak navrhuješ strategii "poslední má pravdu".

Ne, prvni zapis vyhrava.

S takovým systémem jsem dělal a z pohledu uživatele děsně napřesdržku.

Ale o tom jsem uz psal. Na urovni databaze interakci s uzivatelem neresis, databaze je tu k praci s daty. Interakci s uzivatelem musis resit na jine vrstve, na jine urovni abstrakce, protoze kazda situace vyzaduje sve specificke reseni.

Nebylo by lepší mu před tou půlhodinou říct, že na stejném reportu právě dělá Máňa a ať se spolu domluví?

Tak to resis na urovni aplikace.

Zamykáním není pesimistický přístup. Řeší konflikt přesně ve chvíli, kdy nastane, ne půl hodiny později.

Ano, je. Bezne se to tak v databazovem svete oznacuje. A resi ten konflikt pred tim nez vubec nastane, pricemz konflikt ani nastat nemusi, protoze napriklad k zapisu druhym uzivatelem nedojde.

Třeba u ERP mi přijde nezamykání o hodně horší strategie z pohledu uživatele.

Na takovych systemech jsem delal (protoze tehdy nic jineho nebylo), a problemy, kdy se nekde neco zaseklo, byly na dennim poradku. Kdyz se pak delala migrace na SQL a transakcni zpracovani, tyto problemy zmizely a ke kolizim pri soubezne praci prakticky nedochazelo.

[xvasek]

Můžu se zeptat na nějaké reálné případy toho "špatného" zamykání? Protože ve chvíli, kdy stejnou fakturu projeví zájem upravit Jéňa i Máňa, tak podle mého opravdu není na místě tajně doufat, že jeden od svého úmyslu nakonec upustí a konflikt nenastane.

Podle mého to "zamykat moc" a "zamykat málo" spíš pramení z toho, že to lidi implementovali v klasické RDBS nebo něčem takovém a šlo (a fungovalo) jim to blbě, protože - jak píšeš - to není (v RDBS) triviální. Zamknout třeba hlavičku faktury i řádky a hlídat, aby to nikde "neprotékalo", se zdá být pro SQL RDBS opravdu jako místo, kdo se může hodně věcí po...kazit. Právě proto mi přijde jako celkem dobrý nápad mít možnost zámku objektu (!) jako takového už na úrovni skladiště dat.

Protože odpovědi, že "se to řeší na úrovni aplikace" nebo "na jiné vrstvě" je v podstatě přeloženo "ok, na toto je RDBS tupá".

Na takovych systemech jsem delal (protoze tehdy nic jineho nebylo), a problemy, kdy se nekde neco zaseklo, byly na dennim poradku. Kdyz se pak delala migrace na SQL a transakcni zpracovani, tyto problemy zmizely a ke kolizim pri soubezne praci prakticky nedochazelo.

Haha, takto to hodnotí oddělení vývoje. Stačilo uživatelům vysvětlit, že vlastností systému odteď je, že neumí předcházet konfliktům, nemusí to posílat na hotline a teď už je to jejich problém.

[kralyk z abclinuxu]

Právě proto mi přijde jako celkem dobrý nápad mít možnost zámku objektu (!) jako takového už na úrovni skladiště dat.

Přijde mi, že v tom tvém návrhu Jéňa má možnost si zamknout fakturu a (ať už omylem nebo schválně) znemožnit Máně (a celý aplikaci) přistupovat k faktuře. Může případně admin aplikace ten zámky obejít? Pokud ano, nebylo by smysluplnější je mít v aplikaci spíše než na DB vrstvě? Zkus se zamyslet nad řešením tohoto těchto problémů a třeba dojdeš k tomu, že zámky nejsou supr na všecko a proč existují transakce...

[kralyk z abclinuxu]

(Omlouvám se za překlepy. I have sexdaily.)

[xvasek]

Samozřejmě že admin nesmí mít možnost zámky obejít, co by to bylo za bordel? To je zase to zvrácené RDBS myšlení - "aplikační server mi to nedovolil, tak to naprasím rovnou do SQL". Takový přístup přece nesmí existovat v produkčním prostředí ani nad SQL strojem.

[kralyk z abclinuxu]

Takže když Jéňa zamkne fakturu a odjede na dovču, tak s tím nic neudělá ani admin? Chápu to správně?

[xvasek]

Ne, prostě zrušíš ten proces. To je to stejné, jako když jej zruší Jeník v GUI. Zámek to kontrolovaně vezme s sebou samo, ale se zámkem samostatně manipulovat nelze.

[kralyk z abclinuxu]

Jaký je v tom rozdíl? Co znamená "zruší ten proces"? Přijde mi, že stále tam v důsledku dojde k odemčení zámku jiným uživatelem, než který ho zamknul, tj. obejití.

A máš případně nějaké řešení na to, aby tu situaci nemusel ručně řešit admin?

[xvasek]

To jsou různé věci. "Zruší proces" znamená, že to (samo) uklidí do stavu, jaký byl předtím, než ten daný uživatel začal daný objekt zpracovávat.

Obejití zámku jsem si představoval tak, že někdo si něco zamkne, pracuje na tom a někdo jiný ten zámek obejde a provede nějakou změnu na tom zamčeném objektu, popřípadě že zámek zruší a nechá aplikaci v dojmu, že tam ten zámek pořád je.

Vzniklou situaci si mezi sebou vyřeší normálně uživatelé bez zásahu admina.

[kralyk z abclinuxu]

"Zruší proces" znamená, že to (samo) uklidí do stavu, jaký byl předtím, než ten daný uživatel začal daný objekt zpracovávat.

Hmm. To mi z ní povědomě. _{^{Neříká se tomuhle náááhodou transakce?}}

Obejití zámku jsem si představoval tak, že někdo si něco zamkne, pracuje na tom a někdo jiný ten zámek obejde a provede nějakou změnu na tom zamčeném objektu

Což je přesně to, co se stane, když to admin zruší...

Vzniklou situaci si mezi sebou vyřeší normálně uživatelé bez zásahu admina.

Nevyřeší, protože Jéňa je na dovolené a nebere telefony.

[kralyk z abclinuxu]

Což je přesně to, co se stane, když to admin zruší...

Respektive není to to samé v tom, že aplikace se nedostane do nekonzistentního stavu (což bych ani nechtěl navrhovat jako řešení.) Ale stále tam je ten problém, že admin někomu zruší práci, ie. to zamykání zjevně nevyřešilo ten konflikt, pouze ho odložilo.

[xvasek]

Tak když tam ten konflikt opravdu je, tak se asi sám nevyřeší a někdo se tím bude muset zabývat. To tady říkám pořád, ale je mi neustále oponováno, že tam konflikt buď není, nebo je to blbě navržené a řeší se to "v jiných vrstvách" apod. a já furt říkám, že můžou určitě existovat horší řešení (že si to uživatelé budou přepisovat nebo jim to konflikt nahlásí až při uložení), ale že tady takový early warning mi pořád přijde (v kontextu úpravy faktury) jako nejlepší. Jestli máš nápad na nějakou lepší logiku z pohledu uživatele, pořád na ni čekám.

[kralyk z abclinuxu]

Jestli máš nápad na nějakou lepší logiku z pohledu uživatele, pořád na ni čekám.

Tak jistěže mám, ale nechci to jen tak napsat, protože k SQL/RDBMS máš zjevnou averzi. Proto pokládám ty otázky. Už jsme díky tomu došli k transakcím, což je supr. Dále třeba kdyby ses zamyslel nad návrhem té aplikace tak, aby uživatelé nemuseli volat kolegovi na dovolenou, jestli by laskavě nebyl od té dobroty a neodemkl jim zámek, tak bychom třeba došli i k tomu, v čem jsou ty zámky špatné a v čem je ta detekce kolize lepší...

[xvasek]

Tak oni mu samozřejmě nevolají a tu "transakci" si stornují, ale napiš lepší řešení. (A k SQL/RDBMS averzi nemám, to jsou super stroje, mám averzi k jejich bezpodmínečnému užívání vždy a všude.)

[kralyk z abclinuxu]

Tak oni mu samozřejmě nevolají a tu "transakci" si stornují

Jakože jeden uživatel stornuje rozdělanou práci jinému? Uhhh.

ale napiš lepší řešení

Řešil bych to bez zámku jen s transakcemi. Uživatel upravuje data a ve chvíli, kdy je chce uložit se řeší konflikt, může se např. ukázat rozdíl a dotázat co s tím. Klidně může už v průběhu úprav existovat varování, že někdo na stejných datech pracuje, ale měl by to být jen informativní flag na úrovni aplikační logiky, neměl by to být tvrdý zámek na úrovni DB.

Mně osobně přijde, že to řešení se zámkem má oproti tomu pouze nevýhody. Přijde mi, že v tom tvém řešení směšuješ dohromady použití zámku jak pro zajištění konzistence/integrity dat (víceméně konvergence k ACID) tak i pro řešení souběhu úprav uživateli. Je IMHO lepší, když se tyhle věci řeší odděleně - to je IMHO to, co se ti tady snaží někteří říct s tím řešením "na jiné vrstvě".

Nevidím důvod, proč by tahle úloha měla být problém se SQL/RDBMS. Svůj návrh nevydávám za univerzálně lepší řešení, je to lepší pouze z mého pohledu a mohl jsem něco přehlédnout.

[kralyk z abclinuxu]

Řešil bych to bez zámku jen s transakcemi.

... respektive je klidně možné, že na té DB vrstce se něco zamykat bude, byť třeba implicitně, to už záleží na technických detailech toho, jaká DB je použita, jak jsou ty faktury uloženy, atp. Ale IMHO by to nemělo souviset s logikou aplikace.

[xvasek]

...a předpokládáš, že uživateli bude příjemnější, když se při uložení faktury dozví, že ji mezitím upravil někdo jiný, než kdyby mu systém už na začátku řekl, že fakturu upravuje někdo jiný a má se s ním domluvit. Jak už jsem psal, toto řešení je dobré pro support, který uživateli vysvětlí, že to je vlastnost a nebude mu s tím pomáhat, ale jestli to je lepší i pro toho uživatele si musí zodpovědět on sám.

[kralyk z abclinuxu]

...a předpokládáš, že uživateli bude příjemnější, když se při uložení faktury dozví, že ji mezitím upravil někdo jiný, než kdyby mu systém už na začátku řekl, že fakturu upravuje někdo jiný a má se s ním domluvit.

Ne, přečti si to prosím ještě jednou, zejména viz tato část:

Klidně může už v průběhu úprav existovat varování, že někdo na stejných datech pracuje, ale měl by to být jen informativní flag na úrovni aplikační logiky, neměl by to být tvrdý zámek na úrovni DB.

Ono v tom tvém návrhu to beztak je v zásadě taky jen varování, jestliže jeden uživatel může úpravy druhého uživatele zrušit, jak jsi psal.

[xvasek]

A to uděláš "nativně" v RDBS?

[kralyk z abclinuxu]

Co udělám "nativně" v RDBS?

[kralyk z abclinuxu]

Jestli myslíš ten flag, tak třeba Postgre poskytuje advisory locks, ale osobně mi nepřijde nijak moc užitečný vymýšlet nějaké DB-specific řešení (na co?). Řešit to na aplikační úrovni IMHO poskytuje větší flexibilitu - mohl bys třeba i mít záznamy o tom, kdo tu fakturu má otevřenou, abys věděl, za kým případně jít, že...

[JS1]

Jinde jsem ti psal, ze driv existovaly i samostatne transakcni monitory, tj. program ktery dohlizel nad dojezdem transakci napric databazemi a treba souborovym systemem. Dneska je to mozne mit jako soucast aplikacniho serveru ale popravde nevim, mam pocit, ze to trochu vyslo z mody.

[johnyK]

Tak jistěže mám, ale nechci to jen tak napsat

nezlob se na mne, ale ja jsem si jist, ze nic nemas. ne proto, ze bych te znal, ale protoze delam uz 40 let v IT a ta problematika tu byla vzdy a take tady zustane.

Ta otazka kolegy byla pouze retoricka.

Pravdou je, ze v 90. letech bylo plno aplikaci, kdy uzivatel nacetl data k zpracovani a vse potrebne se zamklo a kdyz byl hotov, tak s updatem se to zase odemklo. Ve firmach s 5 lidmi v kancelari to take neni zadny problem se zeptat kolegu, kdo ma co zamknute, aby pripadne tu agendu/ulohu ukoncil.

Samozrejme se vzdy argumentovalo, ze nejaky takovy zamestnanec zamkne nejaka data a pak odejde na obed, cestou ho prejede auto a co ze se deja pak.

No a v takove firme se proste slo na pocitatc te obeti te dopravni nehody a aplikace se ukoncila bez updatu. Kdyz byl ten pocitac zaheslovan, tak se proste vypnul. To je pragmaticke reseni u malych firem.

Samozrejme se u tech velkych na to musi jit jinak, ale vzdy to bude nejaky kompromis. Co je ale hlavni - transakce s touhle celou problematikou nemaji co delat, nebo lepe receno nemohou s nicim pomoci.

[deda.jabko]

Podle mého to "zamykat moc" a "zamykat málo" spíš pramení z toho, že to lidi implementovali v klasické RDBS nebo něčem takovém a šlo (a fungovalo) jim to blbě, protože - jak píšeš - to není (v RDBS) triviální. Zamknout třeba hlavičku faktury i řádky a hlídat, aby to nikde "neprotékalo", se zdá být pro SQL RDBS opravdu jako místo, kdo se může hodně věcí po...kazit.

Zamykani neni jen problem databazi, i v beznych programovacich jazycich je to vetsinou problem udelat spravne. Spousta lidi se venuje tomu, aby vymyslela neco lepsiho, napr. transakcni pamet, a mohlo se na zamykani zapomenout.

Právě proto mi přijde jako celkem dobrý nápad mít možnost zámku objektu (!) jako takového už na úrovni skladiště dat.

V trivialnim prikladu s fakturou to jde, ale v realnych aplikacich mas objekty provazene do komplexnich struktur, a udelat tam poradne zamykani je casto nad lidske sily.

Stačilo uživatelům vysvětlit, že vlastností systému odteď je, že neumí předcházet konfliktům

Ty konflikty se pochopitelne v pripade vzniku detekovaly. Co to podsouvas? Jen v realnem nasazeni prakticky nenastavaly. Vyhodou bylo, ze uz nenastavaly situace, kdy si nejaky uzivatel zablokoval nejakou cast db a ostatni nemohli pul dne pracovat, nebo ze nejaky modul neuvolnil korektne zamek a muselo se slozite hledat, kde to bylo a nasilne ho uvolnit. Kdyz mas vyrobni podnik a mas takove prostoje, neni to levna zalezitost...

[xkucf03]

V trivialnim prikladu s fakturou to jde, ale v realnych aplikacich mas objekty provazene do komplexnich struktur, a udelat tam poradne zamykani je casto nad lidske sily.

Hlavně mi přijde zvrácené křivit ten datový model podle toho, že teď potřebuji zamykat tuhle množinu dat jako celek. Transakčnost/zamykání je jen jeden z mnoha aspektů. Navíc proč pracovat vždy s nějakými hodnotami/atributy jako s celkem (dokumentem), zatímco jiné mít separované do samostatných záznamů/dokumentů?

Nedává to smysl. Naopak krása RDBMS je v té jednoduchosti -- relace/záznam/atribut -- nic víc, nic míň. Se vším¹ se pracuje stejně a k datům můžeš přijít z libovolné strany (zákazník, položka, objednávka, pobočka...) a nemáš nějaký jeden předurčený pohled, kterým se na to máš dívat a odkud máš začínat pracovat s daty (jako je to např. kořenový element v XML, JSONu, YAMLu atd.²)

_{[1] dokonce i s databázovými metadaty / katalogem, který ti říká, jaké relace a atributy v databázi máš
[2] ovšem to jsou primárně datové formáty pro přenos dat a tam je ten jeden pohled pochopitelný -- nemá to být databáze, ale naopak ten jednoúčelový pohled, např. faktura nebo seznam poboček, katalog zboží atd.}

[xvasek]

Ty konflikty se pochopitelne v pripade vzniku detekovaly. Co to podsouvas? Jen v realnem nasazeni prakticky nenastavaly. Vyhodou bylo, ze uz nenastavaly situace, kdy si nejaky uzivatel zablokoval nejakou cast db a ostatni nemohli pul dne pracovat, nebo ze nejaky modul neuvolnil korektne zamek a muselo se slozite hledat, kde to bylo a nasilne ho uvolnit. Kdyz mas vyrobni podnik a mas takove prostoje, neni to levna zalezitost...

Hele, vysvětli mi jednu věc. Jak se liší "Ty konflikty se pochopitelne v pripade vzniku detekovaly ... Jen v reálném nasazení prakticky nenastávaly" a tím přístupem předtím. Tak pokud konflikt detekuji a předtím jste "zamykali nějakou část db", tak z toho pro mě plyne, že jste to předtím museli zamykat blbě, ne? Pro mě totiž "konflikt detekuji a uživatele tam nepustím" zní dost jako synonymum k "zaknu to pro zápis".

[deda.jabko]

předtím jste "zamykali nějakou část db", tak z toho pro mě plyne, že jste to předtím museli zamykat blbě, ne?

Priznavam, ale netusim, kolikrat mam jeste zopakovat, ze se zamykanim jsou problemy a malokdo je dokaze na cemkoliv trochu vetsim udelat spravne.

Pro mě totiž "konflikt detekuji a uživatele tam nepustím" zní dost jako synonymum k "zaknu to pro zápis".

Moc se fixujes na write-write conflict, ale ony jsou i jine typy konfliktu.

Vezmi si treba ty faktury. Chces nad nimi udelat nejakou operaci, treba nejakou souhrnou analyzu. V tvem modelu je musis vsechny zamcit pro zapis, aby v prubehu vypoctu s nimi nikdo nemanipuloval a vysledky byly konzistentni. V prubehu analyzy nikdo nemuze faktury upravovat, jsou zamcene. Pokud mas MVCC databazi, tak analyza pracuje se snapshotem dat, ktery odpovida zacatku transakce a ostatni uzivatele mohou bez problemu menit data, aniz by to vypocet ovlivnilo.

[xvasek]

Proč bych něco měl v takovém případě zamykat? Bude to úplně stejně nekonzistentní s i bez zámku. Po změně faktury bude výsledek prostě jiný, takový je život.

[xkucf03]

Důležité je, abys měl konzistentní výsledky v rámci dané operace -- a ne, že začneš číst, něco si počítat, zase číst, pak to sečteš... a mezi tím ti někdo měnil data pod rukama. Pak bys sečetl něco dvakrát nebo něco naopak přeskočil a to nechceš.

To je ta konzistence. Ještě lépe je to vidět na převodu peněz z jednoho účtu na druhý a změně zůstatků -- onen profláknutý učebnicový příklad.

[xvasek]

Nerozumím. Pokud jsou změny objektů atomické, tak přece nemůžu nic přeskočit nebo číst 2x. Buď přečtu objekt před změnou, nebo po ní a výsledek je v obou případech správný.

[deda.jabko]

Nerozumím

Evidentne. Tak jiny priklad.

Mas tri tabulky: dodane zbozi, vydane zbozi a zbozi skladem. Chces udelat inventuru, podivat se kolik zbozi chybi, prebyva a tak.

V tvem pripade musis zamknout vsechny objekty, aby se v prubehu kontroly nezmenil stav, protoze pak budes mit nekonzistentni vysledky, protoze by se mohlo stat ze zbozi je zaroven vydane i skladem nebo naopak, neni zaevidovane nikde.

S transakcemi u MVCC databazi spustis vypocet k nejakemu konkretnimu stavu a na dalsi upravy behem transakce neni bran zretel, transakce pracuje s daty tak, jak byly v dobe jejiho spusteni. Ostatni uzivatele mohou bez ohledu na to, ze probiha nejaka inventura, klidne pracovat a zapisovat do databaze. Neovlivni to ani inventuru, ani je.

[xvasek]

To je naivní přístup k inventuře. Pokud chceš opravdu dělat inventuru při běhu firmy, narazíš na to, že jsi dal lidem spočítat artikl X a mezi spuštěním inventury v pondělí ti v úterý přišel kamion s 2000ks X, ve středu se dostali k počítání artiklu X a ve čtvrtek vydali 320ks do výroby. Pak to chceš v pátek uzavřít a co dáš do systému za číslo, když jediné spočítané máš to (k začátku i konci špatné) ze středy?

Dělá se to tak, že při inventuře označíš zboží, které ti přišlo, aby jej nepočítali a zboží, které odejde jinam, nahradíš papírkem "tady leželo 320 ks X". Lidi ti pak spočítají (při troše štěstí) stav k otevření inventury, který si stačí při tom otevření zapamatovat a nic zamykat nemusíš.

[deda.jabko]

To je naivní přístup k inventuře.

A? Je to podstatne? Muj prispevek nebyl o nejake inventure, ale o tom ukazat, ze transakcni zpracovani, na rozdil od zamku, snizuje mnozstvi kolizi, ktere jednotlivym uzivatelum brani v praci, coz jsi ty popiral.

[xvasek]

Ano. A pak chceš zamykat něco, co zamykání vůbec nepotřebuje a dokazuješ tím, že zamykání způsobuje problémy.

Pořád si myslím, že zamykání na úrovni databázového stroje a "detekování kolizí" na jiné úrovni je v důsledku to stejné, což tam i píšu.

[deda.jabko]

Ano. A pak chceš zamykat něco, co zamykání vůbec nepotřebuje

Jak neni potreba zamykat? Uz mi dosla trpelivost, tady je kod, at si to muzes vyzkouset.

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class Bank {
	
	private final Account[] accounts;
	
	// vytvori tisic uctu, kde na kazdem je tisic peneze
	public Bank() {
		accounts = new Account[1000];
		for (int i = 0; i < accounts.length; i++)
			accounts[i] = new Account(1000);
	}
	
	// prevede penize mezi ucty
	public void transfer(int from, int to, int amount) {
		accounts[from].lockAccount();
		accounts[to].lockAccount();
		
		accounts[from].withdraw(amount);
		accounts[to].deposit(amount);
		
		sleep();
		
		accounts[to].unlockAccount();
		accounts[from].unlockAccount();
	}
	
	// vrati soucet penez na vsech uctech
	public int audit() {
		int sum = 0;
		for (int i = 0; i < accounts.length; i++) {
			// bonusove zamceni uctu -- stejne nema cenu
			accounts[i].lockAccount();
			sum += accounts[i].balance;
			accounts[i].unlockAccount();
			sleep();
		}
		return sum;
	}
	
	private static void sleep() {
		try {
			Thread.sleep(1);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}

	private final static class Account {
		private int balance;
		private final Lock lock;
		
		public Account(int initialBalance) {
			this.balance = initialBalance;
			this.lock = new ReentrantLock();
		}
		
		public void deposit(int amount) {
			this.balance += amount;
		}
		
		public void withdraw(int amount) {
			this.balance -= amount;
		}
		
		public void lockAccount() {
			lock.lock();
		}
		
		public void  unlockAccount() {
			lock.unlock();
		}
	}

Mas tam tridu Account predstavujici ucty, ktere lze zamykat a menit jejich hodnoty.

Mas tam tridu Bank predstavujici banku, ktera umoznuje prevadet penize mezi ucty a mas tam metod audit(), ktera vrati soucet vsech penez na uctu.

Pak si udelame metodu, ktera bude prevadet penize mezi ucty. Soucet penez na vsech uctech musi byt vzdy stejny.

	
private static void activity(Bank bank) {
	for (int i = 0; i < 1000; i++)
		bank.transfer(i % 1000, (i * 3) % 1000 , i);
}

Overime si, ze vsechno funguje spravne.

	
Bank bank = new Bank();
activity(bank);
System.out.println(bank.audit()); // vysledek je spravne => 1000000

Ted nechame bezet soubezne upravy i audit:

	
Thread transfers = new Thread(() -> activity(bank));
transfers.start();
System.out.println(bank.audit()); // vysledek je blble

Vysledek je blbe, protoze v metode audit() bychom potrebovali zamcit vsechny objekty proti zapisu. To by ale zablokovalo vsechny upravy a xvasek rika, ze to stejne neni potreba.

Pokud ale upravy dobehnou a my udelame soucet znovu, vysledek je opet spravne.

	
Thread transfers = new Thread(() -> activity(bank));
transfers.start();
System.out.println(bank.audit()); // vysledek je blble
		
transfers.join();
System.out.println(bank.audit()); // operace byly dokonceny, vysledek je spravne

Abych to uzavrel, zamykani je potreba a transakce by nedovolily ten spatny vysledek.

Jeste dodam, ze jako bonus pri zamykani si u vice vlaken muzeme vykoledovat deadlock. Vytvoreni deadlocku v tomto prikladu ponechavam jako domaci cviceni.

[xvasek]

Teď mi ještě řekni, jestli bude v praxi zajímavější řešit nějaký in-memory stav "náhodně" se měnícího systému, nebo raději nevytvořit report persistentní v čase, který vezme data z k tomu okamžiku dokončených transakcí, jako se dělá třeba v účetnictví.

(Abys mi dobře rozumněl, já absolutně nezpochybňuji toto řešení tvého problému ani tvůj přístup, který je pro jistou množinu úkolů velmi důležitý, ale pro některé zase naopak úplně zbytečný.)

[deda.jabko]

Nezlob se, ale udivuje me, jak nekdo, kdo se patrne zivi programovanim, je schopen tak male miry abstrakce a skutecneho vhledu do problemu, o kterem diskutuje.

bude v praxi zajímavější řešit nějaký in-memory stav "náhodně" se měnícího systému

Neni dulezite, jestli se jedna o in-memory stav nebo nejaky perzistentni stav, na chovani toho prikladu to nema vliv. To, co jsem ti tu naserviroval na stribrnem podnose, je minimalni ukazka toho, jake problemy mohou vznikat pri pouziti zamku (podle tve predstavy) a jake nevznikaji pri pouziti transakci. Ta ukazka je minimalni, protoze v predchozich prispevcich jsi neco takoveho popiral a bylo evidentni, ze vlastne nevis, co pozadujes a jake to ma dusledky.

Ta ukazka je minimalni take proto, abys mel moznost to pochopit a nemuseli jsme se nimrat v detailech, ktere by skutecnou podstatu problemu jen zastiharaly.

Da se intuitivne predpokladat, ze pokud jsou problemy i v tak trivialnim pripade, ve slozitejsich (realnych) pripadech ten problem bude jeste vetsi, hur odhalitelny a hur resitelny. Na uhybne manevry typu: "ale v praxi se inventura dela jinak" nemam naladu reagovat, protoze ta podstata problemu a diskuze je uplne jinde.

[johnyK]

jake problemy mohou vznikat pri pouziti zamku

Domnivam se, ze tvuj priklad nema ale s tim od pana kolegy nic spolecneho. V jeho prikladu chce jeden uzivatel neco zmenit ve fakture, tak ji zamkne , provede ty zmney a pak to odemkne. Ten druhy uzivatel , ktery musek kvuli tomu zamku cekat provede ty sve zmeny pote. Jak tady muze dojit z hlediska konzistence dat k problemum?

Pan kolega nerika, ze zmena te faktury vyzaduje soucasne atomickou zmenu v nejake jine fakture nebo entite. O tom je ten tvuj priklad.

[deda.jabko]

GOSUB #98
GOSUB #101

[xvasek]

Já ti dám ještě jednodušší příklad. Kdyby sis chtěl poznamenat, že "xvasek je blb", můžeš si buď nainstalovat Oracle do clusteru s vmware a podporou high availability a tam si transakčně a zcela správně bez zámků vytvoříš tabulku a do ní větu s tímto výrokem, nebo napíšeš "echo xvasek je blb>>~/memo.txt" do terminálu. Z mého pohledu jsou _v tomto konkrétním případě_ obě cesty co do finální funkčnosti zcela rovnocenné.

Každý z těchto systémů uložení dat bude vhodný nebo nevhodný podle toho, co s tím budeš chtít dál dělat. Někdy se ti může stát, že se dostaneš do situace, kdy bude záležet osud celého lidstva na tom, že při útoku mimozemšťanů na tuto databázi bude odvráceno zničení planety pouze pokud bude ekvivalent funkce "bank.audit()" nad tímto datovým úložištěm vracet vždy právě 10000. Nebo, pokud například nikdy nedojde k přepisu této informace a ty budeš používat toto datové skladiště pouze pro připoenutí si, kdo je blb, ti tuto funkci na 100% zajistí i ten druhý způsob uložení a přitom si můžeš za ušetřené peníze koupit Porsche.

[xkucf03]

můžeš si buď nainstalovat Oracle do clusteru s vmware a podporou high availability ... ti tuto funkci na 100% zajistí i ten druhý způsob uložení a přitom si můžeš za ušetřené peníze koupit Porsche

Relační databáze nejsou zdaleka jen Oracle. Naštěstí.

[xkucf03]

Ano, lze navrhnout systém tak, aby byl "write-only" resp. "append-only" a všechna data měla časové razítko a zpětně se neměnila. Ale je to hodně limitující (viz níže), zatímco relační databáze ti umí dát konzistentní pohled na živý systém, na měnící se data.

Navíc ten "append-only" přístup je vhodný leda tak pro logy nebo nějaké skladiště dat. V praxi to ale funguje jinak a i v systémech, ve kterých se data nikdy nemažou a nepřepisují, máš stejně nějaké sloupečky typu deleted nebo valid_from a valid_to -- a ty se právě mění.¹ V případě změny hodnoty pak neaktualizuješ hodnotu v záznamu, ale ukončíš platnost valid_to a založíš nový záznam. (případně starý záznam označíš deleted=true).

A pokud ti databáze neumí poskytnout konzistentní pohled k jednomu okamžiku, tak se můžeš trefit do chvíle, kdy starý záznam už je označený jako neplatný a nový ještě nebyl založen (tudíž ti jeden záznam chybí) nebo je založen nový a ještě není označen starý (pak ti jeden záznam přebývá).

P.S. v rámci jedné tabulky to jde ještě obejít tím, že nebudeš mít sloupeček valid_to (ale ani deleted) a záznamy budeš opravdu jen přidávat. Jenže ti to jednak trochu zkomplikuje dotazy a jednak to vůbec neřeší konzistenci napříč tabulkami. Např. když se někdo přestěhuje, tak mu přibude záznam v tabulce adresa, což je sice samo o sobě atomické (v každý okamžik platí právě jedna adresa), ale už to nezajistí atomicitu operací nad více tabulkami, takže databáze bude v určitých okamžicích v nekonzistentním stavu -- a pokud v tu chvíli budeš pouštět nějaké dotazy, budou ti dávat nesmyslné výsledky.

_{[1] tzn. i když to máš z byznys pohledu navržené tak, že se nic nemaže a nepřepisuje, z technického pohledu stejně záznamy aktualizuješ -- ten byznys pohled si můžeš dát do prezentace nebo nějaké brožury a okouzlovat tím zákazníky, ale realita je trošku jiná -- tam to funguje v tom technickém smyslu, kde k přepisům původních záznamů skutečně dochází}

[xkucf03]

Např. když se někdo přestěhuje, tak mu přibude záznam v tabulce adresa, což je sice samo o sobě atomické (v každý okamžik platí právě jedna adresa), ale už to nezajistí atomicitu operací nad více tabulkami

P.S. a nemusí to být konzistentní ani nad jednou tabulkou -- např. kdybys měl evidenci nájemníků a dva se dohodli na vzájemné výměně -- oběma přidáš do tabulky jeden záznam -- jenže tam budeš mít okamžik, kdy máš v jednom bytě dva nájemníky a ten druhý byt je prázdný.

[xvasek]

Navíc ten "append-only" přístup je vhodný leda tak pro logy nebo nějaké skladiště dat. V praxi to ale funguje jinak a i v systémech, ve kterých se data nikdy nemažou a nepřepisují, máš stejně nějaké sloupečky typu deleted nebo valid_from a valid_to -- a ty se právě mění.¹ V případě změny hodnoty pak neaktualizuješ hodnotu v záznamu, ale ukončíš platnost valid_to a založíš nový záznam. (případně starý záznam označíš deleted=true).

Díky za rozumnou debatu. Ano, takto to opravdu v RDBS chodí a ta implementace je "vachrlatá" přesně způsobem, kterým popisuješ. Pak se vytvoření těchto vlastností normálně přesouvá na úroveň aplikačního serveru. Já zase navrhuju přesunout tuto "službu" o úroveň nížen úroveň databázový stroj. (Nemusí být pro všechny tabulky, ale pro vybrané ano.)

Že jeden záznam nějakou dobu chybí považuji ve většině kontextů za umělý problém. Uvedu příklad - posílám si peníze z FIO do ČS a tak nějak počítám s tím, že bude existovat několik hodin až dnů, kdy mi můj audit(vsechny_moje_ucty) bude dávat haluzní výsledek. Takto to v životě chodí, musím s tím počítat, transakční zpracování mi nepomůže. To stejné s těmi nájemníky. Udělal jsem si simulaci a zavedl nájemníka A v bytě 1, nájemníka B v bytě 2. Pak jsem přesunul nájemníka A do bytu 2 a čekal jsem konec vesmíru, zhroucení Internetu nebo aspoň pořádný výbuch v počítači, ale nic takového se nestalo. Report mi opravdu v té chvíli ukazoval oba nájemníky v bytě 2 a byt 1 prázdný. Dal jsem si kafe, dokončil práci a přesunul nájemníka B do bytu 1. Svět pokračoval dále ve své existenci a na konci dne jsem měl oba nájmníky ve svých správných bytech.

Samozřejmě chápu, že existují situace, kdy toto problém je. Například pokud FS zapisuje do konkrétního sektoru, tak sakra záleží na tom, že ten sektor už nepatří žádnému jinému souboru. Ale s přesuny peněz a nájemníků je transakční řešení zcela irelevantní.

[okbob]

Když se podíváte na písmeno I v ACIDu - Izolace transakcí, tak zjistíte, že lze provést přesun z účtu na účet, tak že nekonzistence je vidět pouze v prováděcí transakci, a tam by uživatel měl vědět, co dělá. Jinak pro ostatní uživatele, transakce, je přesun atomický -- tj. jakoby v nulovém čase. Chybějící, nebo přebývající hodnoty rozhodně nejsou umělé problémy - jedná se o klasickou race condition. I když třeba její výskyt není moc pravděpodobný, v momentě kdy nejsou ošetřené, tak mohou nastat. Už jsem viděl aplikace, kde záhadně mizelo nebo se objevovalo zboží ve skladech .. samozřejmě, když byla špička.

Připomíná mi to, jednoho programátora, který mi tvrdil, že nemusím řešit race conditions, bo ty servery jsou tak strašně rychlé, že to nemůže nastat. Ouha nastalo, a to docela často. Stávající svět je nepěkně sesynchronizovaný - a díky tomu hromada událostí vzniká na ms stejně.

Jinak tzv temporální databáze (jsou pokryté i ANSI SQL) řeší delete nastavením systémového atributu. Samozřejmě, že podporují izolaci transakcí.

[xvasek]

Teď z toho začínám mít trochu pocit, jako bych někde tvrdil, že jsem proti transakcím nebo podporuji systémy s race conditions nebo neatomickými operacemi. Transakce jsou dobré (sám používám, doporučuji), race conditions špatné a nemají tam být, atomické operace jsou nezbytné.

Bavili jsme se o tom, co je nutné a co není nutné zamykat; například jestli zaknout stavy skladů v průběhu celé inventury nebo jestli to třeba neudělat jinak.

[kralyk z abclinuxu]

Ale s přesuny peněz a nájemníků je transakční řešení zcela irelevantní.

Panebože do čehos to duši vložil.

[xvasek]

Počky, ty jako myslíš, že pokud nemá software bytového družstva atomické prohození nájemníků, tak nejde používat? To tam na to mají nějakou speciální funkci?

[okbob]

Určitě je možné používat jakýkoliv sw, jen v momentě, kdy začnu vymýšlet neatomické operace, tak mám v systému mnohem víc stupňů volnosti, dynamicky - což minimálně hůře testuje, ladí, uživatelé si pak musí vymýšlet babské rady, typu - nesmíš být tak rychlý, nebo musíš 5min počkat, případně se odhlásit, přihlásit, 10x dát refresh, ..

[xvasek]

Tady.

[johnyK]

hele, ty ses fakt jak umanuty decko. Ja mam hodne velke porozumneni pro tvuj prakticky pristup, ale nemohl by si prosim te uz konecne napsat, ze rel. databaze jsou proste bezva a ze bez transakci to vlastne nejde. Jinak te tu budou presvedcovat do soudnyho dne.

[xvasek]

Hehe, už jsem se o to pokusil, tak uvidíme.

[kralyk z abclinuxu]

Počky, ty jako myslíš, že pokud nemá software bytového družstva atomické prohození nájemníků, tak nejde používat?

Tak jasně, že to (asi) jde používat, stejně jako jde používat software, kde si uživatelé navzájem "zamykají" a zase ruší zámky na fakturách i s rozdělanou prací. Akorát tam prostě zcela zbytečně nastávají problémové situace a hodně se spoléhá na lidský faktor, že s tím bude pracovat správně, aby to nešlo do kytek.

Mně hlavně za celou diskusi není jasné - a zajímalo by mě -, proč preferuješ to alternativní řešení i přes to, že má zjevně více problémů a je náročnější na korektní používání oproti tomu "klasickému" SQL/RDBMS. Přijde mi to jako komplikování si života bez nějakého benefitu.

Osobně jsem se taky setkal s případy, kdy SQL nebylo dobré pro dané použití (např. řešil jsem před pár lety nějaké grafové věci, které se na relace mapovaly celkem špatně), takže souhlasim, že SQL není lék na všechno, stejnětak jiní diskutující tady zmiňovali nevýhody. Nicméně ty use cases, které tu uvádíš ty, mi přijdou jako dost učebnicové příklady pro SQL.

[xvasek]

Oni si ty transakce navzájem ukončí jenom pokud na to mají samozřejmě právo, ale to je vedlejší. Popíšu své zkušenosti.

V první řadě můj aplikační server řeší hodně věcí, které by se jinak musely nějak řešit, už sám. Třeba ty úpravy faktur. Když dám upravit fakturu, tak vím, že se to buď povede, nebo ne, nic mezi. Nemusím řešit, že když je zamčená hlavička, jsou zamčené i řádky, nebo že tam je nějaký hard nebo soft lock nebo že tu fakturu někdo zrovna upravuje. Protože pokud bych šel jen SQL, tak bych nějak musel řešit konflikt mezi uživateli a nějak mezi uživatelem a programem na aplikačním serveru a mezi obecně čímkoli, co by na to sáhnulo, třeba nějaký externí bridge. (Jasně, ve světě RDBS toto řeší aplikační server, nějak.)

Další věc je, že můj aplikační/databázový server řeší ty "read-olny" věci. Faktura je buď aktivní/měnitelná, nebo již zaúčtovaná a tím pádem opravdu neměnná a pokus o update na ní selže. (Opět v RDBS řeší nějak aplikační server, já vím.)

Nemám rád koncept "update ... where ..." - třeba v kontextu výše zmíněné "read-only" politiky. Přijde mi přirozenější upravovat záznamy spíš jako objekty stylem načtu - změním - uložím. (Někdy uložím víc různých typů objektů v transakci, jasně, například příjemka upraví stav skladu, atomicky.)

Líbí se pracovat s objektem včetně referencí v něm uložených. Například pokud mám načtenou fakturu a v ní je ference na zemi, já v některých situacích zjistím, že potřebuju ISO kód té země. Pak jej prostě už mám pomocí konstrukce this.zeme.isokod, v SQL světě bych si to musel buď načíst dopředu a nepoužít, nebo formulovat nějakou query později.

Poměrně specifické u mého databázového stroje je, že jedna tabulka může obsahovat objekty více tříd, které se liší (v objektové terminologii) atributy a metodami - např. objednávky, faktury a dodací listy jsou jedna tabulka (to taky není nic úplně neobvyklého ani v RDBS), ale třeba u bžilionu typů konfiguračních záznamů to už tak typické není. Proto jde celý ERP systém poskládat nad cca čtyřiceti "tabulkami", to je velmi přehledné a jednoduché. (Ono je jich tam prakticky víc, běžná instalace aktivně používá cca těch čtyřicet.)

Na to celé se dá samozřejmě namítnout "však to jde úplně normálním SQL strojem a aplikačním serverem". Jasně, to je pravda. Jenomže když chce normální člověk začít něco vyvíjet, tak jaksi musí začít na "nahém" SQL a vytvořit si napřed nějaký aplikační server. K tomu není žádná norma, každý začíná vynalézáním kola a naprasené věci "ze starých časů" se musí nechat jak jsou "for compatibility reasons". Nebylo by pěkné, kdyby (klidně SQL, transakční a plně RDBMS) databázový stroj nabízel sám o sobě i nějaké vlastnosti objektového aplikačního serveru, které si stejně všichni s větším či menším úsilím a úspěšností musí naprasit sami?

[kralyk z abclinuxu]

Na to celé se dá samozřejmě namítnout "však to jde úplně normálním SQL strojem a aplikačním serverem". Jasně, to je pravda. Jenomže když chce normální člověk začít něco vyvíjet, tak jaksi musí začít na "nahém" SQL a vytvořit si napřed nějaký aplikační server. K tomu není žádná norma, každý začíná vynalézáním kola a naprasené věci "ze starých časů" se musí nechat jak jsou "for compatibility reasons".

To není pravda, existují frameworky, ORM, knihovny atd.

To, co popisuješ s těmi objekty, je právě úloha pro ORM. Používal jsem kdysi jedno ORM, které přesně tohle umělo, ale nebudu ho doporučovat, protože bohužel bylo pouze pro smradlavé PHP. Nicméně nevidim důvod, proč by to nemohlo existovat i pro jiné jazyky.

Nebylo by pěkné, kdyby (klidně SQL, transakční a plně RDBMS) databázový stroj nabízel sám o sobě i nějaké vlastnosti objektového aplikačního serveru, které si stejně všichni s větším či menším úsilím a úspěšností musí naprasit sami?

V podstatě ne.

Všimni si totiž jedné věci: Vaše firma tento problém nevyřešila. Vy jste pouze udělali to, co dělají všichni ostatní - naprasili si nějaké vlastní řešení. Vlastně jste v tomhle ještě dál, protože zatímco ostatní mají společné alespoň to SQL, vy nemáte společné ani to a máte to kolo vynalezeno úplně od začátku. To vaše řešení ale zdaleka není použitelné univerzálně. Kolik programovacích jazyků například podporuje? Další výhoda toho SQL "podvozku" je, že občas potřebuješ jít na tu nizší úroveň, třeba z důvodu výkonu nebo si jen momentálně potřebuješ něco vyzkoušet atp. S proprietárním řešením a s řešením, které primárně počítá pouze s tím vysokoúrovňovým přístupem bude tohle dost obtížné, pokud nezná vnitřnosti té databáze.

Takže ono by to nijak extra pěkné nebylo, protože různí lidé požadují od databáze různé věci, používají různé programovací jazyky na různé účely, mají různé nároky na výkon, atd. Proto je to taky obvykle děleno do vrstvev místo řešení stylem "vše v jednom".

[xvasek]

Jenom drobná korekce - ten systém napsali v západním Německu a já už v žádné firmě zaměstnaný nejsem, ale to není podstatné.

A ano, já to všechno beru, včetně výhrady o naprasení vlastní databáze. Jenom (... pokrčení ramen ...) mi přijde, že jsem nikde jinde neviděl aplikační server, který by byl tak orientovaný na uživatelské objekty a tak málo orientovaný na nějakou databázi za ním. I SAP je mnohem víc obálka nad nějakými tabulkami než objektový upravovač / zobrazovač.

[xkucf03]

Zamykáním není pesimistický přístup.

Tzv. optimistické a pesimistické zamykání jsou standardní a zažité termíny. Nemá to znamenat, že pesimistické = špatné. Jen se každý přístup hodí jinde. Klasické zámky (pesimistický přístup) se hodí spíš pro řešení technických než byznysových problémů např. souběh vláken a takový zámek by měl být zamčený jen na co nejkratší dobu.¹ Optimistický přístup se hodí naopak tam, kde jsou delší časy a menší pravděpodobnost vzniku konfliktu, případně tam, kde do procesu může zasáhnout člověk a rozhodnout, kterou verzi použít nebo jak je sloučit do jedné.

A i když dojdeš k tomu, že na z hlediska byznys logiky potřebuješ (pesimistické) zámky, často se to řeší tak, že použiješ nějakou signalizaci, která ostatním řekne, na čem děláš, do čeho nemají hrabat, ale není to tak striktní a nepřekročitelné jako zámky v DBMS.

_{[1] a i pro řešení těch technických problémů a krátkých časů se lidé snaží hledat cesty bez zámků a navrhovat algoritmy a datové struktury tak, aby k zámkům/konfliktům pokud možno nedocházelo}

[xvasek]

Ano, s tímto na 100% souhlasím. Pro různé typy aplikací jsou potřeba různé přístupy.

(Proto nechápu, jak někdo může obhajovat jenom jeden backend na všechno.)

[johnyK]

v databazovych diskuzich se lide obcas ptaji, jak se dela optimisticky 'select for update'

[JS1]

Treba CICS to co popisujes resi, dneska se to typicky resi v aplikacnim serveru taky nejak. Treba Enterprise Java tusim ma take vlastni transakcni monitor, ale vic o tom nevim. Ostatne pokud se chce nekdo rozepsat o tom, jak se dnes resi problemy, ktere driv resil CICS tak klidne muze, rad si to poslechnu. (Mam pocit, ze dnes se hlavne pouziva databaze, ale transakcni monitor jako takovy - treba ktery umi transakce nad ruznymi databazemi a souborovym systemem atp. - moc ne.)

[xvasek]

Jednou jsem viděl ERP systém postavený na AS/400. Přišlo mi to, že ta platforma samotná je v podstatě aplikačním serverem. (Systém byl celkem šílený, udělalo na mě dojem, že při prvním přihlášení do prázdného systému to chtělo definovat, které všechny uživatelovy společnosti a továrny existují.)

[deda.jabko]

ale ta optimalizace je tam prece jenom proto, ze by jinak to relacni paradigma smysluplne nefungovalo.

Relacni model pouze definuje strukturu dat a model pro praci s nimi. Planovac je jen otazkou realizace tech samotnych operaci. Pokud bych chtel (a teda ze uz jsem parkrat chtel), muzu vzit jednotlive fyzicke operatory (ktere realizuji jednotlive operace) a poskladat si je do hezkeho funkcionalniho programu. Takze planovac opravdu neni nutny, ale podstatne usetri praci a patrne udela i veci lip nez ja, protoze ma mnohem lepsi predstavu o pristupovych dobach k disku, apod.

U jinych paradigmat ta optimalizace neni vubec potreba.

To znam, to se mi na jinych jazycich hodne libi. To si tak clovek napise treba v Jave nebo C# program na parovani dokladu, udela to cele v pameti pomoci hash tabulky, aby to bylo rychle. A kdyz nahodou tech dokladu bude hodne a prestane stacit pamet, tak se program sam prepise, aby to parovani probihalo sekvencne pomoci indexu, aby se vsechno nemuselo nacitat do pameti.

[kralyk z abclinuxu]

Já nejsem apriori proti SQL, ať tam klidně je. Ale ať má člověk možnost si zvolit z co-já-vím pěti různých paradigmat rovnou od výrobce databáze

To by se z toho ten výrobce taky mohl picnout. Kromě toho, řada ORM podporuje taky třeba různé DBMS.

protože těch objevujících se a umírajících knihoven tohoto typu je prostě příliš moc na to, aby člověk s některou spojil svou budoucnost

To je z pozice NoSQL dost ironické.

[xkucf03]

Já nejsem apriori proti SQL, ať tam klidně je. Ale ať má člověk možnost si zvolit z co-já-vím pěti různých paradigmat rovnou od výrobce databáze

Tohle umí třeba Caché (objektová DB, ale má i SQL rozhraní) nebo spousty noSQL databází, jejichž autoři časem přišli na to, že se to SQL hodí a následně ho tam dodělali (a i teoretici noSQL vyměkli a zkratku přehodnotili z negace na not only SQL). Otázka ale je, proč se to za celou dobu moc nerozšířilo (kořeny Caché sahají až do 60. let).

Podle mého je jedním z důvodů úspěchu RDBMS relativní omezenost relačního modelu (relace/záznamy/atributy), která je na jednu stranu dostatečně univerzální a na druhou stranu dostatečně jednoduchá na pochopení (na rozdíl od nějakých obecných grafů nebo haldy nesourodých dokumentů).

[xvasek]

S něčím nad Caché jsem se vždycky chtěl potkat, nemáte někdo zkušenost?

[Bystroushaak]

U databazi, ktere pouzivaji SQl se musi ten string 'nekde' vytvorit

A co myslíš že se s tím stringem pak stane? Něco ho naparsuje zpět na AST, projede nad ním optimalizace a zkompiluje to do bytecode.

bez toho to proste nejde.

Můžeš tu mezivrstvu se stringama a SQL rovnou vyhodit a cílit na tu výslednou VM. Viz třeba SQLite Bytecode Engine. V případě třeba postgre to není bytecode, ale "plan", který vykonává executor. Což je +- to samé, jen na jiné vrstvě abstrakce.

[johnyK]

jednoducha odpoved na vas prispevek: nemate pravdu. Kdyz to rozvedu:

SQLite:

v tom dokumentu ktery linkujete rika sam autor, ze ty opcodes se mohou menit, neni to tedy zadna stabilni interface. Navic to delat jak navrhujete by byl totalni nesmysl. Kdyz uz ty stringy nepsat, tak by se v te SQLite sahlo primo k tem Btree-funkcim, coz autor zrovna tak odmita. Minimalne by byly tyto funkce jakasi stabilni interface, kdyby to autor nemenil. Ze to tema ale neni jenom tema uzivatele xvasek dokazuje skutecnost, ze prvni dotaz v tomhle smeru (obejit to SQL) pochazi minimalne z roku 2008.

Postgresql:

zde je obdobna situace, pgsql zde nenabizi ale vubec zadny interface, tedy, ani nejaky predpis, podle ktereho by se ten plan dal na zaklade nejakych uzivatelskych funkci vytvorit, ani nenabizi nejakou obdobu tech pristupnych Btree-funkci jako SQLite. Je zajimave, ze i zde existuje pokus to obejit, coz opet ukazuje, ze ne vsichni jsou s tim psanim stringu spokojeni.

Zaverem:

Krome nejakych exotu existuji v soucasnosti jen 3 rel. databaze, ktere jsou na trhu aktivne nabizeny a maji aktivni podporu, u kterych je mozno se bez tech stringu obejit a presto je mozno potrebna data z te databaze dostat. A ja se vsadim, ze ani jednu z tech databazi vetsina lidi zde nezna. Takze to shrneme - bez tech stringu se neobejdeme!

[Bherzet]

Použití jazyka SQL je jen jeden ze způsobů reprezentace SQL dotazu (nechme teď stranou, že ta zkratka znamená Structured Query Language). Obecně vzato tedy není nutné používat právě stringy. Konkrétní možnosti u té které databáze jsou samozřejmě druhá věc.

[deda.jabko]

Použití jazyka SQL je jen jeden ze způsobů reprezentace SQL dotazu

Dobry postreh, ktery unika prekvapive velkemu mnozstvi lidi.

nechme teď stranou, že ta zkratka znamená Structured Query Language

Mozna je to chyba nechavat stranou, protoze to je jeden z duvodu, proc je SQL tak velky prusvih.

SQL bylo navrzeno jako prostredek pro komunikaci mezi databazi a rekneme mirne zkusenymi uzivateli. Z toho prameni i spousta nelogicnosti a neortogonalit, ktere v SQL jsou a jsou tam jen pro pohodli uzivatelu, protoze si tehdy mysleli, ze je to dobry napad. Pri dynamickem vytvareni dotazu to pak je jen k vzteku.

Problem je, ze v soucasne dobe takto SQL pouziva zanedbatelne mnozstvi a v drtive vetsine pripadu SQL slouzi pro komunikaci mezi aplikaci a databazi. A na tohle je v mnoha pripadech SQL spatna volba. Na jeho misto by patril jednoduchy (klidne textovy) protokol, ktery by umoznil aplikacim jednoduse sestavovat dotazy do formy, ktera bude snadno zpracovatelna databazi, a ktera bude na druhou stranu jednoduse zpracovatelna clovekem. Proste protokol ala HTTP nebo SMTP, kdy vetsinu casu komunikaci zajistuje stroj, ale kdyz je potreba, neni problem komunikovat primo se serverem se znalosti par prikazu.

[xkucf03]

Dobry postreh, ktery unika prekvapive velkemu mnozstvi lidi.

Podobné je to s XML -- to taky není zdaleka jen text s ostrými závorkami, ale existují i jiné formy zápisu téhož logického modelu.

Proste protokol ala HTTP nebo SMTP

V tomhle je napřed LDAP -- přestože není tak promyšlený jako relační databáze, je na něm fajn, že má standardizovaný protokol a dokonce i standardizovaný datový model (resp. knihovnu standardních prvků, ze kterých lze ten model poskládat).

Standardní protokol by se hodil, ale asi v něm vidím jiný přínos než ty -- odpadla by nutnost mít specifické ovladače pro jednotlivé SŘBD. Ale jinak by v tom zásadní rozdíl nebyl. Pošleš dotaz + parametry a pak si taháš výsledky. Jestli je to textový protokol složený z nějakých tokenů/příkazů nebo jestli je to SQL, které se rozparsuje opět na nějaké tokeny, to už mi moc rozdíl nepřijde. Pokud má klientský systém povědomí o dané gramatice a nelepí jen tupě textové řetězce (nebo je aspoň lepí bezpečně a spolehlivě, tzn. escapuje a neobsahuje další chyby), tak pak je vlastně SQL tím protokolem.

Nebo ti nestačí množina funkcí, které jazyk SQL poskytuje a chtěl bys něco víc? Jak jsem tu psal, zajímavé by mi přišlo něco jako GraphQL a nativní podpora v DBMS. Databázový systém by pak mohl lépe optimalizovat některé druhy dotazů. SQL by to sice nenahradilo, ale v některých situacích by bylo fajn mít i jiný způsob dotazování.

Ale i tak je celkem jedno, jestli je to "protokol" nebo zase jen textový retězec s dotazem v určitém jazyce + jeho parametry.

[deda.jabko]

Ale jinak by v tom zásadní rozdíl nebyl.

Zustavas s uvahama prilis na povrchu.

Pošleš dotaz + parametry

Toto uz je samo o sobe neprijemne. Parametry jsou nekde bokem dotazu. Proc by to nemohlo byt integralni soucasti dotazu/protokolu?

Jestli je to textový protokol složený z nějakých tokenů/příkazů nebo jestli je to SQL, které se rozparsuje opět na nějaké tokeny, to už mi moc rozdíl nepřijde.

Jak jsem psal driv, problem je v tom, ze v navrhu SQL se udelalo moc ustupku, aby bylo stravitelnejsi pro lidi, coz pak rozbiji pouzitelnost pro stroje. Z principu treba nelze obecne overit (jen na zaklade metadat), ze nejaky dotaz je validni. Pricemz v relacnim modelu takova omezeni nejsou.

[okbob]

Jak jsem psal driv, problem je v tom, ze v navrhu SQL se udelalo moc ustupku, aby bylo stravitelnejsi pro lidi, coz pak rozbiji pouzitelnost pro stroje. Z principu treba nelze obecne overit (jen na zaklade metadat), ze nejaky dotaz je validni. Pricemz v relacnim modelu takova omezeni nejsou.

Naprosto bezproblémově na základě metadat ověříte, že nějaký dotaz je validní nebo není. Dokonce je k tomu i vysokoúrovňové API - prepared statements.

Jestli je tam problém, pak je jedině v cacheování - hromada metadat je kvůli rychlosti uložená v cache. Vzhledem k dynamice navíc ověření dotazu uděláte bezpečně vůči aktuálnímu stavu - stávající transakci. V příští transakci už můžete mít schéma jiné. Ale pokud zafixujete změny katalogu, a hypoteticky nebudete brát v potaz cache, tak SQL příkazy můžete validovat bezproblémově.

[xkucf03]

Naprosto bezproblémově na základě metadat ověříte, že nějaký dotaz je validní nebo není. Dokonce je k tomu i vysokoúrovňové API - prepared statements.

V zásadě souhlas. Problém může být v případě, kdy se v aplikaci dynamicky lepí dotazy, aniž by se použil framework, který má povědomí o datovém modelu (většinou ORM -- nebo se to ORM sice nejmenuje, ale v principu to mapuje relace na objekty).

Pokud jsou dotazy statické, tak se dají ze zdrojáků vytahat a během kompilace je zkontrolovat proti datovému modelu. Pokud jsou dynamicky generované v ORM, tak by v nich neměly být chyby. Pokud se ale lepí přímo v aplikaci, tak se na případnou chybu přijde až v době běhu aplikace.

[okbob]

SQL je fakticky protokol - pokud někdo vygeneruje nevalidní SQL, tak je to klasická runtime chyba - a je jedno jestli tu runtime chybu dostanu z SQL, XML nebo JSONu. Tady se SQL zbytečně démonizuje. Zrovna tak můžete vygenerovat nevalidní SOAP komunikaci, cokoliv, co generujete za běhu na základě dat.

[deda.jabko]

Naprosto bezproblémově na základě metadat ověříte, že nějaký dotaz je validní nebo není.

A co treba dotaz typu:

select (select foo from bar where baz = 'x') qux;

Pujde rozhodnout ciste z metedat o jeho validnosti?

[okbob]

Samozřejmě. Je to úplně stejná úloha, jako zvalidovat XML nebo JSON - jen je tam komplexnější gramatika. Ale není to zas až taková tragédie.

[kralyk z abclinuxu]

Je to úplně stejná úloha, jako zvalidovat XML nebo JSON

Ne, to teda není, deda.jabko má zřejmě na mysli validnost nejen ve smyslu validní syntaxe dotazu, ale i sémantiky, tj. jestli existuje daná relace s takovými a makovými sloupci atd.

IMHO v podstatě jde o analogii statické analýzy ve staticky typovaných jazycích. Staticky typované SQL, které by se dalo staticky analyzovat třeba oproti deklarativně specifikovanému schématu DB nebo podobně, bych vnímal jako velké vylepšení, připadalo by mi to jako mnohem lepší cesta dopředu něž nějaké šiblé NoSQL ústřely (čest výjimkám) ...

[xkucf03]

Ne, to teda není, deda.jabko má zřejmě na mysli validnost nejen ve smyslu validní syntaxe dotazu, ale i sémantiky, tj. jestli existuje daná relace s takovými a makovými sloupci atd.

Vždyť tam píše "na základě metadat" -- to chápu tak, že ví, jaké tabulky, sloupce, funkce atd. jsou v cílové databázi k dispozici. Pak je to stejné jako u XML, kde máš zase XML Schéma a validuješ proti němu.

[deda.jabko]

Vždyť tam píše "na základě metadat" -- to chápu tak, že ví, jaké tabulky, sloupce, funkce atd. jsou v cílové databázi k dispozici.

Kralik ma pravdu. Nejde jen o syntaxi ale i semantiku. Problem v tom prikladu je, ze syntakticky je sice vyraz spravne, ale nelze rozhodnout, jestli vysledek bude validni nebo chyba, protoze az na zaklade dat se urci, jakeho typu vysledek selectu bude -- jestli skalar, mnozina hodnot (sloupec) nebo relace (pricemz je to vsechno relace). Cimz se dostavame do stavu, kdy pri jednom zavolani muze byt vysledek v poradku a pri druhem to muze skoncit chybou.

[okbob]

Tak o kterých se bavíte metadatech? Jinak pokud budu mluvit za Postgres, tak výsledné typy se určují v planning time - tj. při validaci SQL. Při provádění dotazu se spočítají pouze data, ale datové typy, použité funkce, použité operátory - to vše se určuje v planning time, ještě před optimalizací - a pouze na základě metadat. Jelikož většina SQL RDBMS má prepared statements, tak bych tipoval, že u dalších db to bude téměř stejné.

[deda.jabko]

Tak o kterých se bavíte metadatech?

Obecne jakaycholiv metadatech, ktera se zadavaji pri deklaraci tabulky, ale to neni podstatne.

U dotazu

select (select foo from bar where baz = 'x') qux;

je problem s tim vnitrnim selectem, protoze pouze na zaklade dat (nikoliv metadat) lze rict, jestli vysledek bude tabulka s jednim radkem a jednim sloupcem (a bude to chapane jako skalarni hodnota). V momente, kdyz budu mit v tabulce dva zaznamy takove, ze baz = 'x', pak vysledek dotazu bude chyba -- z meho pohledu se bude jednat o nevalidni dotaz.

[Josef Kufner]

Pokud bude na sloupci foo unikátní index, tak je výsledek jasný jen z metadat (tedy skalární hodnota nebo null). Pokud tam nebude, tak by ti měla databáze vynadat, že ti tam chybí agregační funkce, nebo unikátní index. Některé databáze ti to dovolí a budou doufat, že se to povede, některé nemusí.

[deda.jabko]

Pokud tam nebude, tak by ti měla databáze vynadat, že ti tam chybí agregační funkce, nebo unikátní index.

A ktera to skutecne udela? Zatim jsem zadnou nepotkal. Vzhledem k tomu, ze tam muze byt libovolny vyraz, nebude to s tim indexem tak jednoduche.

[xkucf03]

Pokud se nějaká honodta vejde do foo, tak se vejde i do qux, takže problém s počtem sloupců by nastat neměl, ne?

Co se týče počtu řádků: teoreticky by se mohl kompilátor podívat na metadata, zda nad daným sloupcem existuje primární klíč nebo unikátní index a pokud ne, tak by považoval dotaz již předem za chybný, protože by mohl vrátit více záznamů. Pak by mohla nastat situace, že záznam s baz = 'x' neexistuje, což na základě metadat ověřit nelze. Tam by tě mohl systém donutit to napsat např. max(foo) místo foo, abys tento případ ošetřil a explicitně řekl, že v případě chybějícího záznamu se má vrátit NULL a ne chyba.

Máš nějaké řešení tohoto problému? Obávám se, že tohle moc řešit nelze a některé otázky zůstanou otevřené a půjde je rozhodnout až v době běhu programu, kdy znáš všechny parametry/data. Maximálně tě systém může skrze kontrolované výjimky donutit, abys všechny tyto situace ošetřil.

[deda.jabko]

Máš nějaké řešení tohoto problému? Obávám se, že tohle moc řešit nelze a některé otázky zůstanou otevřené a půjde je rozhodnout až v době běhu programu, kdy znáš všechny parametry/data. Maximálně tě systém může skrze kontrolované výjimky donutit, abys všechny tyto situace ošetřil.

Proc tak slozite? Stacilo by mit k dispozici operaci typu relace -> skalar (s dobre definovanym chovanim) a nemuze se stat, ze by tam vznikla behova chyba. Chyba se bud odhali za prekladu, mas relaci, tam kde ma byt skalar, nebo dostanes skalar vzdy (byt by to byl treba null).

Co se týče počtu řádků: teoreticky by se mohl kompilátor podívat na metadata, zda nad daným sloupcem existuje primární klíč nebo unikátní index a pokud ne, tak by považoval dotaz již předem za chybný

Prisne vzato, relacni model umoznuje mit i relace jako hodnoty, takze v tom takovy problem neni. Chyba je spis v tom, ze SQL kvuli tomu, aby slo efektivne implementovat a bylo user-friendly, to nepodporuje a resi takove veci mirne receno nekonzistentne.

[xkucf03]

Stacilo by mit k dispozici operaci typu relace -> skalar (s dobre definovanym chovanim) a nemuze se stat, ze by tam vznikla behova chyba.

Můžeš použít max(), min(), avg()... jasně definované chování to má. Jak chceš, aby to vybralo jednu hodnotu, když je jich víc?

Chyba je spis v tom, ze SQL kvuli tomu, aby slo efektivne implementovat a bylo user-friendly, to nepodporuje a resi takove veci mirne receno nekonzistentne.

Nevím, co předně myslíš... Nicméně je potřeba si uvědomit, že ten jazyk/protokol mezi aplikací a databází neexistuje ve vzduchoprázdnu a sám pro sebe. Někdo (programátor, analytik, uživatel...) musí ty dotazy vymyslet, navrhnout, odladit a pak se teprve zabudují do programu a v rámci něj provádějí. A když se má udělat změna, tak se ten dotaz z programu vyjme, někdo ho upraví a pak se do programu zase vrátí. A tady je obrovská výhoda SQL, že mu jednak rozumí i neprogramátoři, a jednak, že i když to dělá programátor, může dotazy vyvíjet/ladit/testovat/cokoli i mimo daný program.

Tolik k uživatelské přívětivosti. Co se týče možnosti efektivní implementace -- kdyby to implementovat nešlo nebo to bylo velmi pracné či pomalé, tak bychom taky žádné implementace RDBMS nemuseli mít. Nebo by jich bylo méně, byla by mezi nimi menší konkurence... pro uživatele by to bylo ve výsledku horší.

Neříkám, že je SQL dokonalé (není, pořád se dá zlepšovat). Ale pokud bych si měl vybral mezi nějakým teoreticky čistým bajtkódem a dnešním SQL, které muselo udělat nějaké ústupky z těch dvou výše jmenovaných důvodů, tak bych bral raději to SQL.

Teoreticky by mohlo existovat SQL pro lidi a ten druhý jazyk/protokol pro stroje, ale nepřijde mi to moc praktické.

Nad SQL vznikla spousta zajímavých frameworků a knihoven. Myslíš, že nad tím "dokonalejším" protokolem by mohlo vzniknout něco, co nad SQL ne? Nebo by to bylo nad SQL jen o trošku pracnější nebo by si ten programátor jen párkrát zanadával, ale nakonec by to nad dím SQL dal? Myslíš, že je tu něco revolučního, o co přicházíme kvůli tomu, že tu máme jen SQL a ne ten jiný dokonalejší jazyk/protokol?

[Bherzet]

A když se má udělat změna, tak se ten dotaz z programu vyjme, někdo ho upraví a pak se do programu zase vrátí. A tady je obrovská výhoda SQL, že mu jednak rozumí i neprogramátoři, a jednak, že i když to dělá programátor, může dotazy vyvíjet/ladit/testovat/cokoli i mimo daný program.

Na to není nutně potřeba SQL.

[xkucf03]

Není, ale jaké jsou jiné možnosti?

Buď to bude úzce spjaté s daným programovacím jazykem. Nebo to bude zase nějaký dotazovací jazyk, pravděpodobně dost podobný SQL. Existuje třeba XPath a XQuery pro práci s XML databázemi, nebo existují nějaké objektové dotazovací jazyky, nebo to GraphQL. Ale přijde mi, že nic z toho nedosahuje kvalit a praktické použitelnosti SQL.

Takže říkat, že SQL je nedokonalé, je sice pravda, ale je to nekonstruktivní, protože jiné možnosti jsou ještě horší. Pokud někdo dokáže napsat lepší náhradu za SQL, tak mu fandím a klidně to pak časem budu používat, ale přijde mi, že nic takového na obzoru není -- takže do té doby budu celkem spokojeně psát svoje SELECTy :-)

[Bherzet]

V případě Monga je možné dotazy na úrovni jazyka sestavovat pomocí builderů, které mají podobné API jako Mongo shell. V Javě je to samozřejmě horší, v Pythonu lepší.

U Elasticsearche je to divočejší, protože má REST API a interní binární API (nebo aspoň měl, zaspal jsem pár verzí). Klienti pro Javu existují AFAIK dva a dotazy se sestavují opět pomocí builderů, ale neexistuje žádný shell, kam by bylo možné dotaz s drobnými kosmetickými úpravami přenést. Dělat ručně složitější dotazy na REST API např. pomocí curl je utrpení, pročež existuje Sense, který má ale úplně vlastní syntaxi dotazů (víceméně je to jen jiné kódování REST dotazů). Kdybych měl Sense k něčemu přirovnat, tak k SQL Server Management Studiu, ale mnohem omezenějšímu.

Otázkou je, proč by dotazovací jazyk (nebo API) měl být zcela nezávislý na programovacím jazyce. Umožnuje ti to spustit dotaz mimo daný jazyk s minimem změn (většinou asi stačí jen nahradit placeholdery), což se může hodit pro ladění. Ale jak moc to potřebuješ? Ladící konzole může spouštět přímo fragmenty kódů v daném jazyce a pak to můžeš mít opravdu 1:1 (vč. toho, že si můžeš nějak zpracovat odpověď). Hned na to se nabízí otázka, jestli je potřeba vytvářet nový program s vestavěným editorem kódu a nestačilo by zahrnout API, které vrátí např. analýzu daného requestu apod. A to přesně přinejmenším ty nové verze Elasticsearche umí (vypadá to trochu neohrabaně, ale to půjde zabalit do pár vlastních metod, aby to rovnou vyblilo na stdout čitelný výsledek).

Pak si můžeš dotazy sestavovat a posílat přímo z IDE ve svém zvoleném jazyce. Je to horší než u SQL, ale dá se s tím fungovat taky. Bohužel nemůžu říct, že zrovna dotazování u Elasticsearche by se mi líbilo, protože to jejich dotazování (ať už na straně Java klienta, nebo skrz ten zmiňovaný Sense) mi vždy přišlo dost výřečné. Nejhorší je, když v dokumentaci vidíš příklady v syntaxi pro Sense a API pro svůj jazyk si musíš dohledávat jinde – ono se to občas dost liší. To asi možná bude důvod, proč nakonec zkouší adaptovat SQL taky. Obecně mi Elasticsearch přijde jako ukázkový příklad projektu, který NoSQL těžce nezvládl a kdyby jej použili rovnou (s minimálními nutnými modifikacemi pro své operátory apod.), byly by mnohem dál (protože udržovat tolik různých API musí být utrpení i pro ně). Je to škoda, protože to je jinak docela fajn projekt.

Aby bylo jasno, já nějaké NoSQL moc neřeším. V práci se to používalo, tak jsem si na to zvykl, ale samotné „NoSQL“ považuji za hype, který je nejvíc populární u fanatických odpůrců všeho statického a typovaného (asi proto, že je to nutí si to dopředu víc rozmyslet).

[deda.jabko]

Můžeš použít max(), min(), avg()... jasně definované chování to má. Jak chceš, aby to vybralo jednu hodnotu, když je jich víc?

To by bylo definovane operacemi. Chtel bych zduraznit, ze nerikam, ze v SQL nejde napsat dotazy, ktere jsou validni a delaji neco konkretniho, ale (a to je podstata problemu) ze nejde overit, ze dany dotaz je validni bez znalosti dat.

A tady je obrovská výhoda SQL, že mu jednak rozumí i neprogramátoři, a jednak, že i když to dělá programátor, může dotazy vyvíjet/ladit/testovat/cokoli i mimo daný program.

Ale pokud bych si měl vybral mezi nějakým teoreticky čistým bajtkódem a dnešním SQL, které muselo udělat nějaké ústupky z těch dvou výše jmenovaných důvodů, tak bych bral raději to SQL.

To silne zavani falesnou dichotomii. Muze byt dotazovaci jazyk, ktery je konzistentni i snadno srozumitelny a hezky se mapuje na relacni model. Doporucuji nahlednout do nektere z knih od C.J.Data a H. Darwena.

Nad SQL vznikla spousta zajímavých frameworků a knihoven. Myslíš, že nad tím "dokonalejším" protokolem by mohlo vzniknout něco, co nad SQL ne?

Problem SQL je, ze neni spatne natolik, aby s tim lidi chteli neco delat. Na druhou stranu dynamicky nad tim sestavovat dotazy neni 2x prijemna zalezitost.

Teoreticky by mohlo existovat SQL pro lidi a ten druhý jazyk/protokol pro stroje, ale nepřijde mi to moc praktické.

Jeste jinak. Predstav si, ze bys mel navrhnout dotazovaci jazyk nad relacnim modelem s dnes. Vazne by vypadal jak SQL?

[okbob]

Tím se SQL neliší od žádného programovacího jazyka, kde může nastat dělení nulou. Jinak ovšem, čistě teoreticky, pokud by sloupec baz byl primárním klíčem nebo k němu byl unikátní index, tak máte garantované, že to nikdy nespadne, a pokud by nebyl, tak by bylo možné vyhodit warning už při statické analýze.

[okbob]

Jinak dneska se tenhle zápis spíš používá jen jako assert, kdy chcete aby Vám to spadlo, v případě, že něco nebylo unikátní. Jinak je to prapůvodní zápis, který se 20 let nedoporučuje používat - ani ne tak kvůli tomu, že může vyhodit runtime error, ale kvůli tomu, že je to korelovaný poddotaz, který databáze uměly vyhodnocovat pouze nested loopem, který je nejpomalejší.

Mám problém s tím, co považujete za nevalidní. Obecně se za nevalidní kód bere něco, co neprojde překladačem, ne něco co mi nikdy nehodí runtime error nebo u čeho mám garantováno, že to vždy doběhne.

Např. SELECT * FROM tab WHERE x = (SELECT val FROM tab2 WHERE ...) je podobný a mnohem častější případ. Opět dnes se používá spíš jako assert, kdy chci mít garantováno, že data jsou v nějaké podobě, a pokud nejsou, tak chci runtime error. Pro Vás by to bylo nevalidní chování, pro mne naopak plně validní a chtěné. Nicméně vyžadujete validitu ve Vašem pojetí, tak není nic jednoduššího než konstrukce, které jsou citlivé na počet řádků nepoužívat. Subselect ... FROM tab WHERE x IN (SELECT val ...) Vám runtime error nikdy nevyhodí.

[deda.jabko]

Jinak je to prapůvodní zápis, který se 20 let nedoporučuje používat - ani ne tak kvůli tomu, že může vyhodit runtime error, ale kvůli tomu, že je to korelovaný poddotaz, který databáze uměly vyhodnocovat pouze nested loopem, který je nejpomalejší.

Vim, ale chtel jsem to uvest jako co nejjednodussi priklad.

Obecně se za nevalidní kód bere něco, co neprojde překladačem, ne něco co mi nikdy nehodí runtime error nebo u čeho mám garantováno, že to vždy doběhne.

To je trochu argumentace stylem - it's not a bug, it's a feature. A taky definice kruhem, dotaz je validni, kdyz jej zpracuje prekladac a prekladac zpracuje jen validni dotazy, protoze pokud by jej nezpracoval, nebyl by to validni dotaz, ... Problem, ktery jsem vytahl je (z meho pohledu), ze SQL umoznuje formulovat dotazy, ktere nelze provest, a pak se to resi runtime errorem, coz povazuji za chybu v navrhu toho jazyka. Cimz cela tato vetev diskuze zacala.

[okbob]

Ok, pak ale takovou chybu v návrhu mají všechny procedurální jazyky - případně všechny jazyky, které mohou vyhodit runtime error. To mi přijde mimo realitu.

[deda.jabko]

Problem je v tom, ze tato cast SQL neni proceduralni, ale deklarativni, a hlavne, relacni model se bez problemu obejde bez runtime vyjimek. Pokud ma tedy SQL reprezentovat dotaz v relacni algebre a potrebuje k tomu runtime vyjimky, evidentne neco bude spatne.

[okbob]

Vyjma SQL/PSM je SQL neprocedurální. Některé konstrukce v SQL ale nejsou čistě relační - což je OFFSET, LIMIT, CTE, nicméně praxí se ukázalo, že jsou praktické.

Asi jste nepochopil moji analogii - dnes Vámi zmíněný subselect použiji k otestování unikátnosti, a chci aby mi to spadlo. Pokud nechci, nejsem si jistý daty, nevím co dělám, atd, tak tuto konstrukci nepoužiji.

Pokud si vzpomínám, tak existují čistě relační dotazovací jazyky - např. D. Dost možná neobsahují konstrukce, které mohou vyhodit runtime error - mimochodem runtime error vám může vyhodit už obyčejný sort na out of memory, ale vzhledem k horši čitelnosti se nerozšířili.

[deda.jabko]

Asi jste nepochopil moji analogii

Ja jsem tu analogii moc dobre pochopil, ale pro tuto diskuzi mi neprijde podstatna.

dnes Vámi zmíněný subselect použiji k otestování unikátnosti, a chci aby mi to spadlo

To je ve sve podstate zneuziti konkretniho chovani SQL a urcite tento ucel nebyl zamyslen jeho tvurci.

Pokud nechci, nejsem si jistý daty, nevím co dělám, atd, tak tuto konstrukci nepoužiji.

To je uz otazka praktickeho pouziti a z tohoto pohledu chapu tvuj ciste pragmaticky pristup. Na druhou stranu ta diskuze zacala tim, ze jsem poukazal na to, ze SQL obsahuje nelogicnosti a neortogonality. Pri rucnim vytvareni dotazu se to ztrati, ale kdyz potrebujes sestavovat dotazy dynamicky podle nejake slozitejsi logiky, jsou takove detaily hodne k vzteku. Pokud by SQL bylo navrhovano s ohledem na tento fakt, urcite by bylo konzistentnejsi.

Pokud si vzpomínám, tak existují čistě relační dotazovací jazyky - např. D.

D je jen teoreticky koncept jazyka vychazejiciho z relacniho modelu, ktery ma nekolik ruznych implementaci. Asi nejznamejsi je Tutorial D (resp. Rel), ktery se pouziva ve vyuce. Na druhou stranu, neni vubec spatne podivat se na databaze a SQL i z jineho uhlu pohledu. Datovy a Darwenovy knizky jsou v tomto smeru super a docela zmenily muj pohled na databaze. Navic, kdyz clovek zkusi delat s databazi, ktera zahodi kompatibilitu s SQL a drzi se principu relacniho modelu, zjisti, ze to dotazovani v SQL je obcas hodne nestastne.

[okbob]

To je uz otazka praktickeho pouziti a z tohoto pohledu chapu tvuj ciste pragmaticky pristup. Na druhou stranu ta diskuze zacala tim, ze jsem poukazal na to, ze SQL obsahuje nelogicnosti a neortogonality. Pri rucnim vytvareni dotazu se to ztrati, ale kdyz potrebujes sestavovat dotazy dynamicky podle nejake slozitejsi logiky, jsou takove detaily hodne k vzteku. Pokud by SQL bylo navrhovano s ohledem na tento fakt, urcite by bylo konzistentnejsi.

Je otázkou, jestli by mainstream dotazovacích jazyků bylo SQL, kdyby preferovalo teoretickou dokonalost místo praktičnosti. Relačně lepším jazykem byl Ingresový Quel (byl ještě v prvních verzích Postgresu), a kde je mu teď konec. Viz třeba celá diskuze kolem NULL, nebo kolem CTE. Poddotazy, a zvlášť korelované poddotazy beru jako historickou záležitost. Jsou jednoduché pro naučení, jednoduše se s nimi pracuje - ale špatně se optimalizují (ale nevnímám je jako chybu v návrhu jako ty, v tom se neshodneme - jejich logika je naprosto jasná). Na druhou stranu dá se bez nich žít, a já osobně při jednodenních kurzech SQL poddotazy vůbec neřeším - a ukazuji jenom JOINy.

SQL od konce osmedesátých let, kdy bylo postavené nad poddotazy, dostalo mnohem silnější aparát - ať je to čitelnější zápis outer joinů, lateral joiny nebo zmiňované CTE. Zároveň je to stále jednoduchý a názorný jazyk, který se může naučit kdokoliv během dvou hodin v hospodě u pivka. Nemyslím si, že SQL je nekonzistentní v relačním aparátu (ale rozhodně nejsem relační dogmatik a nemám rád akademické diskuze) - nekonzistenci vidím spíš v designu funkcí - ANSI SQL posledních 20 let kodifikuje syntaxe se kterými přichází Oracle nebo DB2, a funkce pro Json a pro XML toho moc společného nemají - ale to je problém živého jazyka, a tvorby průmyslového standardu. Tvůrci teoretických jazyků mají ten komfort, že nemusí dohánět praxi.

[deda.jabko]

V zasade s tebou souhlasim.

Je otázkou, jestli by mainstream dotazovacích jazyků bylo SQL, kdyby preferovalo teoretickou dokonalost místo praktičnosti. Relačně lepším jazykem byl Ingresový Quel (byl ještě v prvních verzích Postgresu), a kde je mu teď konec.

Nejenom v IT plati, ze obcas vyhraje ta horsi varianta. A celkove bych na moudrost davu nespolehal. Obzvlast, kdyz clovek vidi ty zastupy lidi, kteri se pousti do ORM nebo JavaScriptu, protoze to tak vidi u ostatnich.

Na druhou stranu dá se bez nich žít, a já osobně při jednodenních kurzech SQL poddotazy vůbec neřeším - a ukazuji jenom JOINy.

To me pripomnelo davna leta s MySQL 3.x, kdy si clovek vymyslel neco s vnorenymi dotazy, aby si to pak mohl prepsat jako cviceni na JOINy.

[okbob]

Nejenom v IT plati, ze obcas vyhraje ta horsi varianta. A celkove bych na moudrost davu nespolehal. Obzvlast, kdyz clovek vidi ty zastupy lidi, kteri se pousti do ORM nebo JavaScriptu, protoze to tak vidi u ostatnich.

Můžete mít špičkovou technologii, ale bez uživatelů, zákazníků, kteří ji budou umět používat žádný byznys neuděláte. A bez byznysu nemáte zdroje na rozvoj. Vůbec si nedělám iluze o moudrosti davu - na druhou stranu, technologie, která přežije 10 let - případně se masově rozšíří, tak kvalitu bezpochyby má. Krátkodobě se uživatelé dají zmasírovat, ale pokud během 5let neukážete reálné zjevné hodnoty, tak Vás převálcuje konkurence.

[Bherzet]

technologie, která přežije 10 let - případně se masově rozšíří, tak kvalitu bezpochyby má

MS Windows?

[johnyK]

proboha neodpovidejte na to nikdo, jinak tady bude zase 1000 prispevku o nicem

[deda.jabko]

U me vede MS-DOS. Na to, ze na tom slo tak maximalne spoustet hry a viry, tak mel hodne tuhy korinek.

[Bherzet]

Pravda.

[kralyk z abclinuxu]

Jinak pokud budu mluvit za Postgres, tak výsledné typy se určují v planning time - tj. při validaci SQL. Při provádění dotazu se spočítají pouze data, ale datové typy, použité funkce, použité operátory - to vše se určuje v planning time, ještě před optimalizací - a pouze na základě metadat.

Ano, ale některé SQL queries podobné těm co napsal děda.jabko generují sub-queries a tam tohle platit nebude ne? Ie. planning se udělá pro subquery a pak nad tím se udělá ta vrchní query...

Můžu se mýlit, ale IMHO pro obecnou SQL query tu validaci do důsledku udělat nemůžeš, IMHO narazíš na obdobu halting problému.

[xkucf03]

Vzhledem k tomu, že tam nemůžeš mít cykly a odkazovat se na něco, co se odkazuje na tebe (což bys při použití WITH mohl napsat, ale DBMS ti to právě nedovolí), tak by to mělo jít vyhodnoti vždy, ne?

[kralyk z abclinuxu]

IMHO když se do toho vloží nějaké složitější CTE, tak ne. Např. AFAIK bys mohl joinovat v závislosti na datech, vytvořit tak dynamické sloupce a na tom třeba dělat nějaký select nebo něco, takže ten vrchní select nepůjde zverifikovat jen na základě metadat.

Podle googlu je SQL s rekurzivními CTE turing complete, takže s tím můžeš zřejmě dělat arbitrární vylomeniny...

[okbob]

V planning time se plánuje dotaz kompletně od top po všechny subquery. Tam, kde to jde, se snažíte poddotazů zbavit - převodem do top query nebo do JOINu.

SELECT * FROM (SELECT * FROM tab) WHERE

sel interně v planning time optimalizuje na

SELECT * FROM tab WHERE

Typy jsou kompletně dané v planning time - SQL je relativně hodně typově striktní jazyk (minimálně v moderním pojetí SQL a obecně v Postgresu), a RDBMS je lepší si představit jako klasický překladač než jako interpret.

[kralyk z abclinuxu]

Ok, dík za upřesnění...

[xkucf03]

To je ale normální. V dotazu můžeš volat třeba funkci, která při určitých hodnotách spadne a shodí ti celý dotaz. Je to asi jako když ti program při určitých hodnotách spadne na dělení nulou nebo NullPointerException. Stát se to může, přesto jde program zkompilovat.

Asi se shodneme na tom, že je dobré toho co nejvíc zkontrolovat staticky, v době kompilace. Ale některé věci v tu dobu zkontrolovat z principu nelze, tak nemá cenu se tím trápit.

pricemz je to vsechno relace

Ano, je to relace. V programu pak můžeš mít určité předpoklady, jako např. že v ní bude právě jeden záznam s jedním atributem -- a pak použiješ třeba JDBC template a metodu queryForObject(), která na tomto předpokladu stojí. Když to spustíš se špatnými parametry nebo na špatných datech, tak ti to spadne na EmptyResultDataAccessException / IncorrectResultSizeDataAccessException.

Ale tohle bych nepovažoval za chybu nástroje, protože je to principiální záležitost -- abys dokázal na téhle úrovni ověřit správnost programu, musel bys mít k dispozici vstupní parametry a data -- a to hodnocení správnosti by bylo platné jen pro tato data/parametry.

[deda.jabko]

Je to asi jako když ti program při určitých hodnotách spadne na dělení nulou nebo NullPointerException. Stát se to může, přesto jde program zkompilovat.

Ale některé věci v tu dobu zkontrolovat z principu nelze, tak nemá cenu se tím trápit.

Ale toto jde resit. Staci k tomu mit vhodne prostredky. V Jave pro to mas treba kvuli NPE Optional<T> A ma argumentace se tyka toho, ze SQL tyto prostredky nema.

Ano, je to relace.

Ano, vzdy je takovy vyraz relace. Problem je, ze nekdy je ten vyraz taky skalar a nekdy ten samy vyraz zase skalar neni. A pak se v tom vyznej.

[xkucf03]

Ano, vzdy je takovy vyraz relace. Problem je, ze nekdy je ten vyraz taky skalar a nekdy ten samy vyraz zase skalar neni. A pak se v tom vyznej.

Tam jde o automatické přetypování, ne?

Ono ti projde třeba i tohle:

SELECT '123' + 456

To jsou asi ty kompromisy mezi uživatelskou přívětivostí a čistotou/dokonalostí.

Takže bys vlastně chtěl, aby SQL bylo přísnější a musel jsi v něm udělat explicitní přetypování nebo zavolat nějakou funkci, která ti z relace vytvoří skalár?¹ Mi spíš na SQL vadí ty věci, které v něm chybí, než ty, které v něm přebývají.²

Přijde mi, že se tu hádáme o blbostech a jsou daleko důležitější úkoly k řešení.

_{[1] BTW: Co by ta funkce dělala, kdyby v té relaci bylo více záznamů/atributů? IMHO by měla vyhodit výjimku -- což je ale přesně to, co se dneska děje. Akorát tu funkci/přetypování nemusíš volat explicitně
[2] Ano, chápu, že v systému by správně nic přebývat nemělo... ale pokud to nepřesahuje rozumnou míru a nezpůsobuje škody, tak ať je tam radši pár funkcí navíc, které nepoužívám. Jinak by si totiž každý musel napsat svůj vlastní jazyk, který splňuje jen to, co daný člověk potřebuje, a nic víc.}

[xkucf03]

Zustavas s uvahama prilis na povrchu.

Zkus to rozvést.

Toto uz je samo o sobe neprijemne. Parametry jsou nekde bokem dotazu. Proc by to nemohlo byt integralni soucasti dotazu/protokolu?

Vždyť parametry můžeš vždycky psát jako součást dotazu. Jen je často výhodnější je psát zvlášť a vědět, že jde pořád o tentýž dotaz s jinými parametry, než že to jsou dva různé dotazy.

Ten princip je všude stejný, jen si každý databázový systém předává ty dotazy a parametry trochu jinak. Je škoda, že tu není protokol, jako má třeba ten LDAP, který by standardizoval interakci mezi klientem a serverem. Máme sice nějaká sjednocující API jako JDBC, ODBC, PDO, DBI atd. ale pořád k nim potřebuješ ovladač pro danou databázi.

Byl by to čistější a správnější přístup. Ale na druhou stranu: pokud by tím šlo zadávat v principu stejné dotazy jako dnešním textovým SQL, tak by to z praktického hlediska nebyla až tak zásadní změna. Zásadní by bylo rozšíření možností jazyka, aby lépe podporoval třeba objektový nebo grafový pohled na data... ale je relativně jedno, jestli tohle rozšíření bude v textovém SQL s parametry bokem nebo v nějakém novém protokolu.

[okbob]

Databáze jsou starší než TCP/IP - takže si každý matlal komunikační protokol vlastní - dělat to dneska - tak vezmu HTTP - nechám si poslat SQL, GraphGL, a vrátím XML, JSON. Takové aplikace už dneska existují - používání nativních protokolů je do jisté míry setrvačnost. Funguje to, problémy s komunikací nejsou, tak nikdo nemá nutkání něco překopávat. Stavět novou databázi - tak ji postavím nad HTTP. To jsou detaily - které samozřejmě až tak nic nemění. Lidem, co mají averzi k SQL, to samozřejmě jejich problém nevyřeší.

[xkucf03]

Použít k tomu HTTP mi přijde nešťastné. Lepší by byl protokol založený na obousměrném posílání zpráv.¹ Databáze by pak mj. mohla posílat zprávy klientovi např. notifikace na změnu dat nebo obecně zprávy (v DBMS by mohl být volitelně integrovaný message broker, správa queue/topic) a fungovalo by to transakčně.² Mohlo by tam být otevřeno více výsledkových sad současně a klient by si je mohl tahat na přeskáčku, jak potřebuje -- nebo by to mohlo být řízené serverem a ten by posílal data, kdy je má k dispozici, a klient by si ty výsledky poskládal. Princip posílání zpráv je mnohem univerzálnější než princip požadavek/odpověď. A ideálně by to mělo být myšlenkově kompatibilní s reaktivním přístupem.

_{[1] K HTTP jsou sice dodělané WebSockety, ale to je zbytečná vrstva navíc, zbytečné zesložitění... HTTP je dost zatížené historií, zpětnou kompatibilitou. Kdyby se navrhoval nový protokol pro databáze, tak by mohl být mnohem jednodušší a čistější.
[2] např. můžu vložit zprávu do fronty a říct, že chci, aby se poslala ostatním, až když udělám COMMIT; nebo naopak vložím zprávu tak, aby se odeslala hned, a tedy i při ROLLBACKu}

[deda.jabko]

Zkus to rozvést.

Zustavate v rovine syntaxe a ty problemy SQL spis vidim v rovine semantiky. Pokud by to SQL bylo navrhovano jako protokol, ne jazyk pro lidi, hromada nelogicnosti by z podstaty odpadla.

Ten princip je všude stejný, jen si každý databázový systém předává ty dotazy a parametry trochu jinak.

Toto je z podstaty rovnak na ohejbak. Neni duvod, proc by dotaz i parametry nemohly byt predavany stejnou cestou. Ale uz je to proste tak zazite, ze to proste vetsine lidi prijde normalni.

pokud by tím šlo zadávat v principu stejné dotazy jako dnešním textovým SQL

To by asi melo. Kdyby ta komunikace byla navrhovana ne jako jazyk (pro lidi), ale jako protokol pro stroje, vysledek by vypadal jinak -- asi by tam byla lepsi typova bezpecnost, zmizely by ruzne neortogonality. Coz si myslim, ze by byl zajimavy prinos zejmena, pokud potrebujes dotazy generovat dynamicky.

[Josef Kufner]

Pokud by to SQL bylo navrhovano jako protokol, ne jazyk pro lidi, hromada nelogicnosti by z podstaty odpadla.

Například?

[deda.jabko]

V rychlosti treba jednotny mustr pro dotazy, s tim souvisi zbytecna dvojice HAVING a WHERE, nestacil by jeden? Nemoznost pouzit vyraz ze SELECT v HAVING, nemoznost overit, jestli je dotaz spravne. Viz diskuze vyse, kdy jednou je vysledek SELECTu bran jako skalarni hodnota, jindy jako sloupec a jindy jako relace a rozhodnuti zavisi na datech nikoliv metadatech.

[xkucf03]

V rychlosti treba jednotny mustr pro dotazy, s tim souvisi zbytecna dvojice HAVING a WHERE, nestacil by jeden?

SQL umožňuje oboje (příklad)

S HAVING:

SELECT
    mena,
    count(*) AS pocet
FROM zeme
GROUP BY mena
HAVING count(*) > 5;

S WHERE:

SELECT * FROM (
SELECT
    mena,
    count(*) AS pocet
FROM zeme
GROUP BY mena
) AS m
WHERE pocet > 5;

Proč ti vadí, že SQL umí něco navíc? Vždyť to nemusíš používat. Možná je to syntaktický cukr, ale nepřijde mi, že by způsoboval nějaké problémy a v jeho odstranění nevidím přínos a podle mého to neopodstatní přechod z SQL na něco jiného.

Nemoznost pouzit vyraz ze SELECT v HAVING

Tohle umí např. SQLite:

SELECT
    a,
    count(*) AS pocet
FROM (
SELECT 'a' AS a, 1 AS n UNION
SELECT 'b', 1 UNION
SELECT 'b', 2 UNION
SELECT 'c', 1 
)
GROUP BY a
HAVING pocet > 1

Zkoušel jsem to teď v PostgreSQL 10.5 a tam to nejde. Ale je to jen otázka implementace -- nic co by v textovém SQL z principu nešlo.

kdy jednou je vysledek SELECTu bran jako skalarni hodnota, jindy jako sloupec a jindy jako relace a rozhodnuti zavisi na datech nikoliv metadatech

Vždy je to relace, ne? Počet atributů by měl být pevně daný, nebo ne? Počet záznamů závisí na datech, s tím souhlasím.

[deda.jabko]

SQL umožňuje oboje (příklad)

Vim, ale to jen dokresluje tu nekoncepcnost, ktera byla zavedena kvuli tomu, aby byl jazyk vhodny pro lidi.

kdy jednou je vysledek SELECTu bran jako skalarni hodnota, jindy jako sloupec a jindy jako relace a rozhodnuti zavisi na datech nikoliv metadatech

Vždy je to relace, ne? Počet atributů by měl být pevně daný, nebo ne? Počet záznamů závisí na datech, s tím souhlasím.

Jak by se ti libilo, kdybys mel treba v Jave funkci getFoo(), ktera by jednou vratila Integer a jindy treba List<Integer>, s tim, ze tvuj kod by vypadal (musel vypadat) nejak takto?

Object o = getFoo();
int bar = ((Integer) o).value() + 1;

Taky by sis rikal, ze proste takove chyby se stavaji, ze je to jako NPE?

[xkucf03]

Jak by se ti libilo, kdybys mel treba v Jave funkci getFoo(), ktera by jednou vratila Integer a jindy treba List<Integer>, s tim, ze tvuj kod by vypadal (musel vypadat) nejak takto?

Ono je to spíš tak, že ta funkce vrací vždy List<Integer> a ten jazyk ti dovolí výsledek přiřadit do proměnné typu Integer a zajistí v tom případě automatické přetypování (resp. vezme ze seznamu tu jednu hodnotu). Ale jen pokud v tom seznamu není víc hodnot. Jinak to vyhodí výjimku. Což je jasně definované chování.

[deda.jabko]

Ono je to spíš tak, že ta funkce vrací vždy List<Integer>

Neni poodstatne, jestli se na to divas z jedne, ci druhe strany. Otazka znela, jestli bys chtel (pripadne mas) takove nakontrolovane pretypovani ve svem programu (treba v Jave).

Jinak to vyhodí výjimku. Což je jasně definované chování.

S tim nepolemizuji. Co vidim jako problem (a tim to cele zacalo), ze nelze jen z metadat rozhodnout, zda takovy dotaz je validni nebo ne. Pricemz, pokud by SQL bylo navrzeno dusledne, takovy problem by nenastal. Stacilo by rict, ze za SELECT se muze objevit jen skalarni vyraz. A to jsou ty ustupky, ktere mi vadi.

[xkucf03]

Toto je z podstaty rovnak na ohejbak. Neni duvod, proc by dotaz i parametry nemohly byt predavany stejnou cestou. Ale uz je to proste tak zazite, ze to proste vetsine lidi prijde normalni.

Nikdo ti přece nebrání napsat:

SELECT * FROM osoba WHERE jmeno = 'Franta';

ale jsem rád, že můžeme napsat i:

SELECT * FROM osoba WHERE jmeno = ?;

Možnost oddělení programu od dat považuji za výhodu.

Coz si myslim, ze by byl zajimavy prinos zejmena, pokud potrebujes dotazy generovat dynamicky.

A jaký by byl praktický přínos? Stejně, když ten dotaz sestavuješ dynamicky, tak ho většinou sestavíš dynamicky těsně před spustěním, takže by ses o chybě dozvěděl stejně až v době běhu. Akorát by to bylo asi v okamžiku nějakého prepareStatement() místo v executeQuery(). Ale vzhledem k tomu, že by se většinou volaly těsně po sobě, tak by to bylo celkem jedno.

[johnyK]

Obecně vzato tedy není nutné používat právě stringy.

ale prakticky je pouzivat musime. Budto pouzijeme jednu z tech mála databazi, ktere se bez toho obejdou a nebo pockame , az nejaky vyrobce treba dodela nejaky takovy dotazovaci protokol ala smtp ,jak stoji v prispevcich dole. Tim sice nebudeme psat nejake stringy, ale za pomoci dalsi mezivrstvy sdelime databazi potrebne informace , ktera muze reagovat 2 zpusoby:

a)

z tech predanych informaci, vytvori zase ten string, predhodi to jako dosud parseru, optimalizatoru etc. a nic se na tech databazi nemusi preprogramovat. V tomto pripade porad pouzivame nejake stringy

b)

z predanymi informacemi nalozi databaze jinak nez doposud, dokonce se bude ptat na jine informace nez doposud a pote co vyrobci tech databazi sve produkty preprogramuji se bez tech stringu obejdeme. Obecne je to skutecne tak, to mate pravdu.

[okbob]

A ta SMTP komunikace není v řetězcích? - pokud si pamatuju, tak to je zrovna textový protokol, jako je SQL

[kralyk z abclinuxu]

a pote co vyrobci tech databazi sve produkty preprogramuji se bez tech stringu obejdeme

Jak? Mně přijde, že neobejdeme. Ta vrstva komunikující s DB bude tvořit nějaké requesty v nějakém formátu tak jako tak, nesnad? Jediný rozdíl je, že ten formát bude třeba jinak vypadat, ale to mi samo o sobě nepřijde jako benefit. V čem by mělo být to vylepšení oproti SQL + abstrakce á la ORM?

[Bherzet]

Ten formát nemusí být textový.

[xkucf03]

Může to být nějaký bajtkód, bude to trochu efektivnější, nebude to svádět k SQL injection chybám... Ale že bych v tom viděl nějaký kvalitativní skok vpřed, to se říct nedá. Režie parsování textového SQL je zanedbatelná oproti času strávenému hledáním dat na disku, jejich načítáním a posíláním po síti. Dokonce i když si předáváš data mezi aplikací a databází ve formě XML a použiješ funkci xmlTable, tak se to v tom ztratí.

[Bherzet]

Však o žádném kvalitativním skoku řeč nebyla. Bystroushaak negoval výrok, že u SQL databází se musí někde vytvářet string. Já se s tím ztotožňuji, tak jsem si dovolil to dovysvětlit místo něj.

[Bherzet]

A čistě z praktického programátorského hlediska, ať se taky dozvím něco nového (protože SQL u svých projektů už nepoužívám a pracovně jsem se s ním setkal jen u jednoho legacy projektu), jak se tedy v praxi to dotazování řeší? Výše zaznělo, že lepit dotazy jako stringy už se prý nedělá (#2, #5). Tak jak se to tedy dělá?

Vyjasnilo se, že databáze jako taková dostane ten SQL dotaz zakódovaný jako string (až na pár výjimek, které podporují něco jiného), takže doslovně vzato komentátoři výše pravdu nemají. To se pak upřesnilo, že to bylo myšleno spíš abstraktně tak, že se ten dotaz prostě poskládá na jiné vrstvě aplikace. Tam vidím asi dva možné patterny: nějaké buildery, pomocí kterých se dotaz zkonstruuje (podobně jako je tomu u driverů pro některé NoSQL databáze), nebo ORM.

První zmíněné implementuje např. Querydsl nebo jOOQ a vypadá to zajímavě, ale na druhou si nemyslím, že to je to, o čem by byla řeč.

Zbývá tedy ORM, což mi někde potenciálně přijde jako kanon na vrabce a bál bych se, jak to bude s výkonem. Např. tady někdo udělal pár benchmarků, které mé obavy potvrzují. Jsou to ale nějaké míň známé ORM pro Node.js (čti: ani jeden z těch názvů jsem nikdy předtím neslyšel), takže předpokládám, že třeba u Hibernate může být situace mnohem lepší.

Je mi jasné, že se to bude lišit projekt od projektu a univerzální odpověď neexistuje. V projektu, který aktuálně udržuji, se load/save objektů řeší prostě ručně na jedné vrstvě aplikace, a docela to vyhovuje – je tam ale minimum relací. Kdyby tam byly, přestala by tahle architektura být výhodná, a dával by už větší smysl nějaký ORM framework. Jenže pokud načtu objekt z tabulky Foo, který odkazuje na záznam do tabulky Bar, který odkazuje na záznam do tabulky Baz, měl bych obavu, že:

• Bude se načítat zbytečně mnoho záznamů, i když nemusí být vůbec potřeba.
  • Pokud by byl implementován lazy-loading, bude to efektivnější, ale k případné databázové chybě dojde později než by mělo (totéž se týká latencí).
• Pokud ORM neumí sledovat, které objekty se změnily, bude do databáze propisovat zbytečně mnoho změn (i pokud databáze bude dost chytrá na to, aby je nepropsala, což snad bude, představuje to úplně zbytečný vyhledávací dotaz).

Jak se tohle řeší? Mají na to ty lepší ORM frameworky nějaké chytristiky, nebo je na programátorovi, aby si to ohlídal a např. v mnou uváděném příkladu explicitně řekl, co se má načítat/ukládat? Bylo by tehdy ORM stále přínosné?

[xvasek]

A teď se do toho zase zamontuju já.

Podle mě není problém ani tak v protokolu, ani v jazyku, ani v textovosti, ale prostě principu práce. Třeba v SAPu je artikl asi v pěti tabulkách. Teď si představne, že máme tři artikly A, B a C. Ve druhé tabulce jsou nastavené logistické parametry artiklů, (minimální stav, doba dodání, ...). Je to v separátní tabulce, protože může být více továren a každá má svoje logistické parametry. Toto není nijak objektově spojené, prostě jsou to dvě úplně nezávislé tabulky. Teď udělám dotaz select from artikly left outer join logisticke_parametry a pokud existuje jenom jedna (nebo žádná) továrna, tak tento dotaz bude generovat tři řádky, jako je artiklů.

Později přibude druhá továrna a stejný dotaz začne najednou vracet více řádků podle toho, v kolika továrnách má který artikl nastavené parametry. Pokud to má být selekce nad artikly, tak to nefunguje. Samozřejmě se dá říct, že to zprznil nějaký mastiflinta, který na začátku měl předpokládat, že může být v systému víc továren. Na druhou stranu, nebylo by mnohem přirozenější, kdyby databáze vracela strukturu:

artikl A:
 -> název,
 -> popis
 -> [logistické parametry v továrně 1, logistické parametry v továrně 2, ...]
artikl B:
 -> název,
 -> popis
 -> [logistické parametry v továrně 1, logistické parametry v továrně 2, ...]
artikl C:
 -> název,
 -> popis
 -> [logistické parametry v továrně 1, logistické parametry v továrně 2, ...]

Stejný "problém" mám s update where. V podstatě jediný "legální" update by měl být vždy po primárním klíči. Proč je update where navrženo tak destruktivně nebezpečně? To stejné delete from...

Já samozřejmě plně chápu ten relační mechanismus a proč to tak je. (I když by se z předchozí diskuse mohlo zdát, že jsem úplně mimo.) V tom problém není. Problém u každého systému, se kterým jsem se setkal, je v tom, že člověk neustále potkává chyby, které (kvůli přílišné volnosti toho modelu) před ním už naprasil někdo jiný. To mi nevyhovuje, já chci něco víc blbuvzdorného od začátku.

[kralyk z abclinuxu]

To mi nevyhovuje, já chci něco víc blbuvzdorného od začátku.

Huh? Z té diskuse o zámcích a transakcích jsem naopak získal dojem, že chceš něco, co je hlavně jednoduché a že to není blbuvzdorné ti až tak nevadí, dokonce ani u finančních operací...

[xvasek]

Hm, to bych tak neviděl. Chci něco jednoduchého a blbuvzdorného, ještě si to tomu přihodím intuitivného. SQL, nebo raději říkejme relační databáze, jsou jednoduché na své specifické úrovni (všechno je relace, vždy dostanu 2D tabulku, navíc s pevným počtem sloupců), ale implementace objektového přístupu v nich není podporovaná, objekt "faktura" (a tím nemyslím jenom triviální hlavička a řádky) prostě není nativním relačně-databázovým principem.

V zásadě mi nevadí vzdát se některých real-world nepotřebných vlastností (např. hromadné update ... where, které se dá intuitivněji nahradit pomocí foreach(objekt) do something) výměnou za vlastnosti, které reálně potřebuji - například aby faktura byla vždy nativně objektová, nebo ideálně abych pro získání atributů z referencovaného objektu nemusel volat nějaký další poddotaz.

Já to noSQL "hnutí" moc nesleduju, ale přišlo mi, že se často v podstatě snaží jenom nahradit ten SQL jazyk něčím jiným, ale princip fungování v podstatě pořád zůstává stejný, což (pokud je to tak) mi zajímavé nepřijde.

[xkucf03]

Později přibude druhá továrna a stejný dotaz začne najednou vracet více řádků podle toho, v kolika továrnách má který artikl nastavené parametry. Pokud to má být selekce nad artikly, tak to nefunguje. Samozřejmě se dá říct, že to zprznil nějaký mastiflinta, který na začátku měl předpokládat, že může být v systému víc továren.

1) Z relačního pohledu se to chová zcela správně a ten pohled je konzistentní. Je to věc, se kterou máš počítat. Je třeba si uvědomit, že nepracuješ s objekty, ale s relačními daty a jak fungují JOINy. Zajímavý by mohl být protkol, který by umožnil přenášet takováto data a říct: "tenhle záznam je stejný jako předchozí, kromě atributů A1, A2..., jejichž hodnoty jsou..." a tím by se ušetřilo na přenosech dat.

2) Dalo by se to řešit nativní podporou GraphQL v RDBMS (vedle SQL).

3) Dneska to můžeš řešit pomocí XML funkcí (v tom třetím sloupci bys měl XML, které by agregovalo záznamy ze všech továren) nebo ORM.

Proč je update where navrženo tak destruktivně nebezpečně? To stejné delete from...

Protože hromadné aktualizace nebo mazání jsou legitimní operace.

člověk neustále potkává chyby, které (kvůli přílišné volnosti toho modelu) před ním už naprasil někdo jiný. To mi nevyhovuje, já chci něco víc blbuvzdorného od začátku.

S tím si ale u NoSQL databází nepomůžeš, protože většina z nich je na tom z hlediska přílišné volnosti o dost hůř než relační databáze a často nemají ani schéma. Trochu by ti pomohlo ORM, které za tebe např. vyřeší ten problém s více továrnami (nestane se ti, že by ti to vrátilo jeden artikl víckrát -- vrátí ti ho to jednou a třída, která ho popisuje bude mít atribut typu List<LogistickéParametry>, ve kterém můžeš mít 0-n objektů).

[xvasek]

1) Z relačního pohledu se to chová zcela správně a ten pohled je konzistentní. Je to věc, se kterou máš počítat. Je třeba si uvědomit, že nepracuješ s objekty, ale s relačními daty a jak fungují JOINy. Zajímavý by mohl být protkol, který by umožnil přenášet takováto data a říct: "tenhle záznam je stejný jako předchozí, kromě atributů A1, A2..., jejichž hodnoty jsou..." a tím by se ušetřilo na přenosech dat.

Že je to relačně zcela správně je sice pravda, ale taky je to prakticky úplně k ničemu. Můj systém mi dává jednotlivé atributy objektů dokonce just-in-time až ve chvíli, kdy je použiji v programu (než začne diskuse o tom, jak je to blbě, tak jenom podotknu, že můžu na začátku vyvolat transakci a ze svého pohledu "zmrazit svět", pokud to uznám za vhodné), což je ještě efektivnější protokol. Ale samozřejmě to vyžaduje mít databázi a aplikační server velmi blízko sebe. Že toto umí ORM je pravda, ale s jakou efektivitou... A hlavně mi neříkejte, že toto je ten způsob, jakým byly SQL databáze myšleny používat.

Jinak NoSQL nevím, nikdy jsem žádný takový obecný stroj nepoužíval, takže těžko soudit. V zásadě jim fandím, ale na druhou stranu myslím, že se příliš snaží být náhradou SQL strojů.

[xkucf03]

Můj systém mi dává jednotlivé atributy objektů dokonce just-in-time až ve chvíli, kdy je použiji v programu (než začne diskuse o tom, jak je to blbě, tak jenom podotknu, že můžu na začátku vyvolat transakci a ze svého pohledu "zmrazit svět", pokud to uznám za vhodné), což je ještě efektivnější protokol.

Co tedy používáš? Schválně pošli nějaké odkazy na dokumentaci a příklady, ať se bavíme o něčem konkrétním.

[xvasek]

Nepošlu, protože je to bohužel uzavřené a dokumentace je pod heslem. (Stránka o systému je tady.) Ale funguje to asi tak, že pokud v programu použiju v kontextu faktury promenna = this.dodavatel.zeme.iso2kod, tak přestože jsem dopředu nikde nedeklaroval, že budu potřebovt iso2kod zeme, tak jej dostanu, systém provede nakoukání do těch referencovaných objektů just-in-time.

Je samozřejmě jasné, že to je vlastnost čistě aplikačního serveru. Ale protože je od začátku počítáno, že to takto budou lidi dělat, zvládne takových nakoukání řádově tisíce za sekundu. Těžko říct, jestli by select from dodavatel, zeme where id = id and id = id bylo taky dostatečně akční. Třeba v MySQL bych tomu i věřil, ale podle mých zkušeností třeba Oracle je sice na velké query machr, ale při bžilionech takových drbek to bývá pěkný lenoch, protože před spuštěním čehokoli si odskočí na kafe a přemýšlí, jak nejlíp na to.

[johnyK]

budu potřebovt iso2kod zeme, tak jej dostanu, systém provede nakoukání do těch referencovaných objektů just-in-time

ja to znam u aplikacnich servru ktere komunikuji s rel. databazi tak, ze si server nacte ty tabulky, ktere jsou dostatecne male a nepodlehaji castym zmenam - takove ty klasicke ciselniky jako ty kody zemi, platebni podminky, druhy expoedice - pri startu a kdyz nekdo chce ten udaj vedet, tak se to necte just-in-time z nejake obzvlast rychle databaze, nybrz je to v nejake strukture uz schovane. Samozrejme , ze to nema nic spolecneho s in-memory databazemi.

Obecne bych rad poznamenal k te diskuzi nasledujici.

Porad se zde vlastne ptas, proc neni takovy styl prace, jak ty ho znas od ABASu bezny i pri pouziti rel. databazi. Ja bych rekl, ze to se musis vlastne zeptat tech panu od ABAS, oni to byli, kteri tenkrat na zacatku 90. let rozhodli, ze si napisi vlastni databazi a spoji ji relativne napevno s aplikacnim servrem. Treba by prozradili, proc se tak rozhodli.

To ma takove vyhody o kterych zde referujes, samozrejme to ma i nevyhody, o kterych ale nemluvis. Napr. ta synchronizace ABAS databaze s tim MS SQL Serverm, kdyz lide chteji nejake obvykle CRM funkce. ABAS to 'prodava' jako feature, ja rikam berle. Kdybychom vedeli, jake vsechny 'berlicky' takovy system obsahuje, mozna by se nam lepe zodpovidala ta otazka, proc se to obecne tak nepoiziva.

[xvasek]

Samozejmě to má své nevýhody, to není žádné tajemství. Například chybí agregační funkce (je potřeba počítat "ručně"), nebo například všechny selekce nad databází jsou svým způsobem jednoduché - musím udělat selekci nad danou třídou nebo třídami objektů (můžu ale selektovat podle atributů referencovaných objektů a dostat atributy z referencovaných objektů) a nemůžu dělat nějaké harakiri typu select from select apod. Pokud něco takového pořebuji, musím si to naprogramovat jako program na aplikačním serveru. Na druhou stranu zase po vlastní zkušenosti takové selekce vlastně v praxi nejsou moc potřeba, pokud je návrh objektů (tabulek) smysluplný. A číst imperativní program foreach(objekt) {mrkni sem} (mi osobně) přijde příjemnější, než nějaký šílený napůl generovaný parametrizovaný SQL statement.

Synchronizaci s MS SQL jsme měli všichni trochu schopnější (partneři) samozřejmě hotovou dřív, než s tím abas přišel sám. Jenom oni ten systém potřebují prodat a proto "na data z abasu se můžete dívat v MS SQL" je must-have feature. Technicky vzato se to původně nabízelo pod mnohem více zavádějícím "abas podporuje MS SQL".

Co se týká stylu práce, těžko nějak exaktně dokazovat, jestli je relační nebo objektový přístup lepší, ale uvedu příklad. Teď dělám třeba integraci s APS systémem třetí strany (pokročilé plánování), která abas nikdy neviděla. Načtení připraveného plánu z Oracle (výrobní příkazy, kusovníky, routingy, přiřazené kapacity...) bude mít cca 100 řádek exportu z Oracle a cca 300 řádek (příkazů) pro nahrání a aktualizaci plánu v abasu, mám na to budget 24 hodin práce. To mi přijde v kontextu všeho, s čím jsem kdy pracoval, tak o desítkový řád lepší.

[xvasek]

Tak, hotovo, převod výrobního plánu z APS mám, celkový čas strávený je 26 hodin, z toho 2 hodiny si vykážu do testování, které jsem tam samozřejmě dělal taky. Řádků je trochu víc než bylo plánováno - 100 je export z Oracle, import má nakonec cca 500 (jeden příkaz na řádek). Aktualizuje to 4 objekty, každý na několik způsobů (založení, aktualizace, smazání). Teď mi řekněte, který jiný ERP něco takového vůbec umí a v jakém čase. Můžu se zeptat kamaráda ze SAPu, ale podle mého navrhne něco mezi 50 a 100 člověkodny.

Dle mého je to jak píše JS1 - pracuji prostě s vhodným DSL. Otázku, jestli je výhodou mít pod tím nějaký podobně specifický "podvozek", nechám asi volně viset v prostoru, už bylo diskutováno dost.

[kralyk z abclinuxu]

Ale funguje to asi tak, že pokud v programu použiju v kontextu faktury promenna = this.dodavatel.zeme.iso2kod, tak přestože jsem dopředu nikde nedeklaroval, že budu potřebovt iso2kod zeme, tak jej dostanu, systém provede nakoukání do těch referencovaných objektů just-in-time.

To je v jakém jazyce? (Tipuju C# a použití Properties.)

Má to podporu i pro jiné jazyky?

[xvasek]

Má to nativní podporu bohužel jenom pro vlastní jazyky (FOP a FO2) a pro Javu. Ale relativně často se používá volání dalších programů na serveru, takže se připojují věci v shellu, perlu, pythonu, co kdo umí. Pak jsou dva přístupy - buď se data pro takový podprogram připraví do souboru nebo předají jako parametry a pracuje se s výsledkem, nebo je možno napsat si klienta pro text-based EDP protokol, který umožňuje povídat si s aplikačním serverem a pak je ta "objektovost" zděděna i do takového jazyka. Já mám třeba vlastní knihovnu s velmi neučesaným (ale funkčním) subsetem volání EDP funkcí pro Perl, takže umím data z abasu servírovat / upravovat například přes apache, nebo jsem si za hoďku napsal "píchačky" v Perl/TK. (Nativní http server pro abas je samozřejmě tomcat.)

V abasu je tedy pak možno pro uživatele transparentně používat například i data z MS SQL, prostě v eventu pro zobrazení obrazovky načtu přes freetds nebo JDBC nějakou query a tu uživateli zobrazím a on nemá tušení, že tato data nepřišla z databáze abasu. Ale počítám, že takovýto "hack" umožňují úplně všechny aplikační servery úplně čehokoli, kde tlustý klient nesedí rovnou nad SQL.

[Bherzet]

Ale to

Ale funguje to asi tak, že pokud v programu použiju v kontextu faktury promenna = this.dodavatel.zeme.iso2kod, tak přestože jsem dopředu nikde nedeklaroval, že budu potřebovt iso2kod zeme, tak jej dostanu, systém provede nakoukání do těch referencovaných objektů just-in-time.

tedy funguje v té Javě jak? Nahradí se instrumentací ten přístup k fieldu za volání metody, která se spojí s databází a tu hodnotu doplní?

[xvasek]

V podstatě ano v AJO (abas java objects), ale pro úplnost je tam několik způsobů přístupu.

V oldschool FOPu / FO2 se napíše prostě:

.formula U|mojepromenna = H|lief^staat^iso2

Což je přiřazovací příkaz, U| jsou moje (lokální) proměné a H| je něco jako "this".

V JFOPu udělám to stejné v javě pomocí:

mojepromenna = EKS.stringexpr("H|lief^staat^iso2")

...ok, nic krásného, JFOP je jenom primitivní java obal na FOPem.

Pak existuje AJO (abas java objects), kde už je to celé zobjektovatělé.

mojepromenna = faktura.getlief().getstaat().getiso2()

(Názvy proměnných/atributů/metod jsou ve skutečnosti v němčině jenom ve FOPu a v AJO jsou anglicky, ale tím nebudeme čitatele mást a necháme vše v němčině.)

Přitom AJO má tu drzost nechat se implementovat nejen server-side, ale jde vytvořit i zcela nezávislý client-side program, který může používat pro přístup k abasu stejné metody, nicméně bude samozřejmě trpět na zpoždění dané síťovou vrstvou.

No a nakonec existuje (text based) EDP protokol (přes který běží mimo jiné i client-side AJO), který to stejné implementuje taky, můžu v něm zavolat:

GFV|nejakepronasnepodstatneparametry|lief^staat^iso2

...kde GFV je "get field value" a server mi zase vrátí na co jsem se ptal.

[johnyK]

mohl by si jeste napsat, jak sdelis o jakou fakturu se jedna (cislo faktury). Asi to bude s nejakym tim 'new', ale ja nejsem javista ani OOP.

[xvasek]

V jakém paradigmatu?

V AJO dostaneš opravdu množinu výsledků:

SelectionBuilder<Invoice> selectionBuilder = SelectionBuilder.create(Invoice.class);
selectionBuilder.add(Conditions.between(Invoice.META.idno, "20000", "30000"));
Query<Invoice> query = dbContext.createQuery(selectionBuilder.build());
for (Invoice invoice : query) {
    něco s tou fakturou dělej
}

Ve FO2 je to víc k věci:

.select invoice "20000!30000"
while (G|success) {
    teď máš jednu fakturu a můžeš s ní něco dělat
    .select continue
}

Já dělám většinou ve FOPu, to je mnohem míň písmenek... Dá se samozřejmě selektovat podle jakýchkoli atributů.

[Bherzet]

Chci utéct do pralesa provádět okultní rituály a modlit se k pohanským bohům, abych takový systém nikdy nepotkal.

[xvasek]

Proč?

[kralyk z abclinuxu]

Já se přidám. Předtím se mi nechtělo zmiňovat ORM pro PHP, protože považuju PHP za humus, ale v kontextu tohohle podvlákna mi to přijde passé , takže tady: RedBeanPHP. Mimochodem to umí dělat s objekty něco velmi podobného jako uvádíš ty, ie. lazy-loading referencovaných objektů., viz např. tady.

Na tom Eks systému bych nechtěl pracovat mimo jiné minimálně už z toho důvodu, že to je nepodobný čemukoli jinýmu a získané zkušenosti by mi tak byly k ničemu kdekoli jinde. Vypadá to, že ten projekt trpí hodně velkým množstvím NIH syndromu. Chápu, že jsou pro to historické důvody, ale v roce $CURRENT_YEAR mi to moc smysl nedává...

To už bych možná byl klidnější i s tim PHP

[xvasek]

Hele, to už mi přijde jako klasický případ xenofobie. Že je to jiné plně chápu, že máš obavu o neuplatnění svých znalostí taky chápu, ale to ještě neznamená, že by to kvůli tomu mělo být srovnáváno s PHP nebo jiná podobná invektiva.

[johnyK]

že to je nepodobný čemukoli jinýmu a získané zkušenosti by mi tak byly k ničemu kdekoli jinde

to je to, co asi kazdeho napadne jako prvni.

Presto musim ale rict, ze jsem rad, ze tu ta diskuze je. Zridka kdy se najde nekdo, kdo ma odvahu prezentovat neco, co neni 'bezne', co nestoji v knizkach jako to 'spravne'. Rikal jsem si ovsem, ze kdyz to nekdo uvidi, tak si radsi zaplati to SQL skoleni u pana Stehuleho.

Presto, kdyz se vratime k tomu hlavnimu tematu - totiz - je to s tim SQL skutecne tak jednoduche ? a nebo maji jine zpusoby reseni svoje opodstatneni - tak pak bych si nebyl tak jisty, ze ten klasicky SQL styl je tak vhodny. Kolega zminil, ze ten ABAS ERP system ma 40 hlavnich tabulek a nejake dalsi k tomu - kdyz to prezenu , tak treba 300. SAP ERP system, ktery vpodstate neumi co se funkcnosti tyce o moc vice, ma tech tabulek 60000. Skutecne , sedesat tisic. Kolega tady psal, ze ted bude delat nejaky transfer a ma na to 3 dny. U SAP by to trvalo minimalne 10 x tak dlouho, jestli by si to vubec nekdo troufnul, protoze dnes uz vpodstate nikdo nevi, jake ty zavislosti v takovem systemu jsou.

A tech podstatne mene tabulek vede automaticky k tomu, ze nejaka tabulka musi obsahovat mnohem vice dalsich informaci, ktere by v relacnim systemu byly rozlozeny na mnozstvi dalsich relaci. Pak je samozrejme, ze se na jeden dotaz nacte mnohem vice dat.

Ale to vsechno je podmineno tim, ze si nekdo napsal vlastni databazi spojenou s tim aplikcnim servrem. To ze to v tomto specialnim pripade jde bez tech 'neohrabanych' sql-statements neznamena, ze bysme se v relacnich systemech mohli bez nich obejit.

Ja jsem se poohlednul na netu, co se o tom ABAS systemu povida a skutecne ma rada potencialnich zajemcu problemy s tou 'neznamou' databazi.

[kralyk z abclinuxu]

Presto, kdyz se vratime k tomu hlavnimu tematu - totiz - je to s tim SQL skutecne tak jednoduche ? a nebo maji jine zpusoby reseni svoje opodstatneni - tak pak bych si nebyl tak jisty, ze ten klasicky SQL styl je tak vhodny.

To je těžká otázka SQL určitě má svoje limity a nevýhody. Pamatuju si šílený JOINy přes půl databáze atd. Na druhou stranu ale stejnětak nevim o ničem, co by bylo významně lepší pro běžné použití. Ten ABAS/EKS to opravdu není už minimálně z toho důvodu, že je to proprietární řešení s vendor lock-inem, kde se člověk bez kontraktu zřejmě nedostane ani k dokumentaci rozhraní. Kdyby existovalo něco takového ve svobodné nebo alespoň veřejné verzi, tak by to možnáv některých případech vylepšení bylo? (Těžko říct takhle bez znalosti detailů.)

IMHO hlavně aby člověk mohl přijít s alternativou takovou, aby skutečně představovala vylepšení oproti SQL, musí SQL opravdu dobře rozumět a znát důvody, proč funguje tak, jak funguje. Jak už jsem předeslal, já bych čistě intuitivně tohle řešení hledal někde v oblasti silně typovaných funkcionálních jazyků, ale necitím se kvalifikován říct, jak by to přesně mělo vypadat...

[JS1]

Jak už jsem předeslal, já bych čistě intuitivně tohle řešení hledal někde v oblasti silně typovaných funkcionálních jazyků, ale necitím se kvalifikován říct, jak by to přesně mělo vypadat...

Mozna takhle?

[xvasek]

Podle mého názoru a pocitu, aby to šlo taky prodat, je to celé o tom, že na správné vrstvě musí být správný jazyk. Silně typované funkcionální jazyky by mohly být asi docela užitečné a zajímavé pro psaní univerzálních funkcí aplikačního serveru. Jakmile by přišlo na psaní uživatelské logiky, kterému musí rozumnět kozultant, programátor implementátora a programátor zákazníka, tak veškeré silně typované funkcionální jazyky musí stranou a musí přijít něco primitivního imperativního, co se podobá pascalu nebo basicu. A samozřejmě sázkou na jistotu je i to SQL.

(A abas nevytváří žádný jiný vendor lock-in, než jiné ERP systémy. Naopak po zakoupení je poměrně velká část systému open source, je normální z toho odvozovat vlastní kód a upravovat to.)

[JS1]

Podle mého názoru a pocitu, aby to šlo taky prodat, je to celé o tom, že na správné vrstvě musí být správný jazyk.

Ano, ale to co pises dal je uplne blbe.

Dostatecne silne typovany funkcionalni jazyk (resp. spise DSL v nem) ti zaruci, ze uzivatelska logika nebude delat veci, ktere nema. Takto to ma treba Facebookovsky Haxl.

Tohle je proste zakladni nepochopeni v nasem oboru. Turingovsky uplne (a imperativni) jazyky by mely patrit do rukou inzenyrum, kteri navrhuji system. Analytici (asi to neni uplne presne oznaceni), kteri zapisuji business logiku, by pak meli pouzivat jen Turingovsky neuplna DSL vhodna pro dany problem (ktera je mozne rozsirit prave ve spolupraci s inzenyrem), protoze znaji konkretni domenu.

Ono to ma dve priciny. Prvni je, ze v realnem svete ta neuplna DSL pro business logiku jsou obvykle nekrestansky draha (ruzne SAPy a podobne), takze se vsude znovu vynaleza kolo. Druha je, ze kazdy chce byt inzenyr, a navrhovat system, nikdo nechce byt delegovan do "druhorade" role analytika (ona neni objektivne druhorada, ale je tak vnimana z duvodu socialni hierarchie ve firmach).

Dalo by se to zmenit tim, ze by si programatori zavedli vlastni komoru, ktera by inzenyry certifikovala a vynutila tohle rozliseni. Ale bude to nejakou dobu trvat, nez se to stane.

IMHO by to zlepsilo kvalitu, protoze obe casti by pak psali specialiste.

A protoze to nikdo v praxi takto nerozlisuje, tak je nedostatek programatoru - lidi, kteri by mohli suverenne delat inzenyrstvi (jako subdodavatele), treba protoze absolvovali IT MFF nebo FIT CVUT, firmy zbytecne plati za to, aby psali business logiku. A naopak lidi, kteri by hrave zvladli domenove specificke DSL, pak postavime pred prekomplikovane systemy v Jave, ktere michaji vsechno dohromady.

Ono driv to tak trochu bylo - na mainframech analytik (rikalo se jim aplikacni programator) umel jen COBOL a inzenyr (systemovy programator, i kdyz to znamenalo i administrator) umel pouzival i assembler, skrz ktery slo aplikace rozsirit. Jenze s nastupem mikropocitacu se to rozdeleni rozpadlo. (A spousta COBOListu skoncila nezamestnanych, bohuzel.)

[JS1]

Asi lepsi by bylo napsat, ze znacna cast toho vyse uvedeneho silenstvi je dana tim, ze dnes obecne skatulkujeme programatory podle jazyku a nastroju ktere pouzivali, misto abychom resili, jake jsou jejich domenove znalosti. A tak se samozrejme nikdo nezene naucit se proprietarni jazyk nebo nastroj. Dusledek je pak moda a znovuvynalezani kola, jak se vsichni znovu uci danou aplikacni domenu, jenom v jinem programovacim jazyce.

Jedinou svetlou vyjimkou, ktera te mode trochu odolala, je prave SQL. A to i pres znacne usili NoSQL hnuti to zvratit.

[xkucf03]

Dost mi to připomíná BPMN/BPEL a tvorbu programů pomocí tahání šipek mezi krabičkami. Částečně to funguje, ale většinou se objeví tak dva ze tří problémů:

• Nástroj je nekřesťansky drahý a/nebo proprietární a vytváří vendor lock-in, prostor pro vydírání jeho dodavatelem.
• Lidi, kteří rozumí tomu byznysu stejně nejsou schopní/ochotní ho používat a mají tendenci tuto práci delegovat na někoho jiného (buď nějakého brigádníka, který do toho zanese chyby, nebo programátora, jehož čas je drahý a navíc si bude připadat nevyužitý).
• Možnosti jsou omezené a spolupráce s inženýrem, který ti upraví chování uvnitř té krabičky, je nutná častěji, než bys chtěl.

Tím nechci říct, že jsem proti nějakým grafickým nebo DSL nástrojům, ale dávají mi spíš smysl jako řešení nějakého dílčího problému, než něco, co spasí IT.

[Bystroushaak]

Tím nechci říct, že jsem proti nějakým grafickým nebo DSL nástrojům, ale dávají mi spíš smysl jako řešení nějakého dílčího problému, než něco, co spasí IT.

Viz A very comprehensive and precise spec. Máš problém, který má nějakou fraktální složitost. Abys ho vyřešil, musíš vytvořit řešení, které jí bude dostatečně dobře reflektovat.

Fraktální složitost řešení (představ si to jako že záhyb fraktálu řešení popisuje jak vyřešit záhyb fraktálu problému) nesnížíš tím, že použiješ grafické klikátko, naopak jí v tom budeš muset zachytit stejně jako v textovém popisu zdrojového kódu.

Ta myšlenka, že grafická klikátka jsou dobrá se imho táhne ze dvou front; 1) Abstrakce že čím abstraktnější programovací jazyk, tím větší efektivita. Tohle ovšem nijak nesnižuje složitost problému, nýbrž jazyka. 2) Kdysi dávno přechod na GUI z textových rozhraní a s tím související zpřístupnění počítačů masám. Z toho plynoucí pocit, že když máš grafickou aplikaci, tak to lidi sami pochopí bez nutnosti se to složitě učit, jako tomu bylo v případě grafického rozhraní. Což může být částečně pravda díky discoverabilitě, ale stejně tomu musíš dát ten čas ať už tak, nebo tak a ovládání myší má zpravidla podstatně menší datový tok než klávesnicí.

Přijde mi zajímavý ten přístup který razí Kay, kde používáš různé transformátory a axiomatické systémy, ve kterých vygeneruješ krátkým popisem něco co má velkou fraktální složitost. Například Towards Moore's Law Software: Part 3 of 3, kde použili generování kódu z RFC datagramů, takže se jim celá implementace TCP/IP stacku vešla pod 200 řádků kódu. To je něco, nad čím stojí za to se zamyslet podstatně víc, než kolik je tomu teď věnováno prostoru.

[JS1]

Rozhodne nemam na mysli tahani sipek.. To rozdeleni uz tady dnes je - kernel a user space. Operacni system je DSL pro aplikacni programovani. Abstrakcemi v tom DSL jsou veci jako treba soubor.

Vsechny tri namitky, ktere mas, plati i pro operacni systemy nejakych 40 let nazpet - jsou proprietarni a musis se s problemy obratit na dodavatele nebo nejakeho jineho experta.

Rikam, COBOL tohle (do znacne miry) respektoval. V databazich vzniklo podobne rozliseni. Ale Java, co se zacala pouzivat na business aplikace, tohle rozdeleni strhla (ono to nebylo Javou jako takovou, duvody jsou spis socialni, jak pisu). Drtiva vetsina business (a obecne aplikacni) logiky ale nepotrebuje Turingovsky uplny jazyk.

[xkucf03]

Rozhodne nemam na mysli tahani sipek..

Jestli taháš šipky nebo píšeš nějaké DSL, je jen forma. Princip je ale stejný. A nad DSL jde často napsat nějaký grafický nástroj. DSL je nějaký omezený prostor, ve kterém jde (pokud možno deklarativně) popsat, co má program dělat. Resp. co má dělat nějaká jeho část (zatímco jiné části tímto způsobem měnit nelze). A pak tak nějak přirozeně dojde k rozdělení rolí, že někdo dělá spíš to jádro a někdo ho spíš používá. Proč by měl být zásadní rozdíl mezi tím, jestli píšeš v nějakém textovém DSL a tím, kdy totéž (např. datové toky, rozhodovací stromy nebo tabulky) popíšeš v nějakém grafickém nástroji? To má být nějaké elitářství a snaha o to, aby se psal aspoň nějaký kód a vypadalo to aspoň trochu tajemně? Zrovna třeba to SQL bys mohl plnohodnotně tvořit v grafickém nástroji. Kdybych nějaký vhodný měl, klidně bych ho používal a nestyděl bych se za to. Naopak -- dovedu si představit, že by takový grafický nástroj měl přidanou hodnotu i pro toho, kdo zná syntaxi a nedělá mu problém to SQL psát ručně.

To rozdeleni uz tady dnes je - kernel a user space. Operacni system je DSL pro aplikacni programovani. Abstrakcemi v tom DSL jsou veci jako treba soubor.

Nikdy jsem nad tím neuvažoval jako nad DSL. Beru to prostě jako vrstvy systému, kde nižší vrstva tě odstíní od toho, co je pod ní, např. můžeš abstrahovat od toho, jakým rozhraním je připojen pevný disk nebo jaký souborový systém se používá. Můžeš vrstvy vyměňovat atd.

Co by se asi dalo považovat za DSL, jsou unixové roury a jejich zápis v shellu -- ty jsou aspoň deklarativní a říkáš pomocí nich: "tudy tečou data", místo abys musel v cyklu číst bajty ze vstupního proudu a přesypávat je na výstup. (mimochodem ty roury a parametry příkazů by šlo opět sestavovat pomocí grafického nástroje a nemusel by je zadávat textovou formou zdrojáku/DSL) Případně ještě uživatelská práva a asi by se našlo i pár dalších věcí... Jinak je ale operační systém hromada služeb postavených na principu požadavek/odpověď nebo zasílání zpráv.

Zažil jsem např. jeden telekomunikační projekt, kde jeden tým tvořil jádro systému a vstupně-výstupní moduly v C++ a druhý tým nad tím psal řešení pro jednotlivé zákazníky. Řešení se skládalo z nějaké deklarativní konfigurace a pak z imperativních skritpů, ve kterých byla ta byznys logika. Ale taky bych tomu neříkal DSL -- byl to obecný skriptovací/programovací jazyk, turingovsky kompletní.

Rikam, COBOL tohle (do znacne miry) respektoval. V databazich vzniklo podobne rozliseni.

COBOL nepamatuji, databáze OK -- SQL beru jako DSL pro práci s relačními daty.

Ale Java, co se zacala pouzivat na business aplikace, tohle rozdeleni strhla (ono to nebylo Javou jako takovou, duvody jsou spis socialni, jak pisu).

Jednak nesouhlasím, protože anotace (a v menší míře i generika) lze považovat za DSL a deklarativní programování. Např. napíšeš metodu obsahující byznys logiku a pak nad ní dáš jednu anotaci a tím ji zpřístupníš po síti jako službu (aniž bys musel imperativně řešit síťovou komunikaci nebo nějaké serializace dat). Totéž platí pro uživatelská práva/role nebo transakce.

A jednak nevím, v čem by měl být problém? Vadí ti, že můžeš psát byznys logiku ve stejném jazyce, ve kterém se píší frameworky a knihovny? Máš snad nějaké DSL, které by bylo použitelné pro popis logiky např. v oblasti bankovnictví a šlo jím nahradit Javu? Navíc, když považuješ OS za DSL pro psaní aplikací, tak nevím, proč nechceš brát Javu (a její frameworky, např. EE nebo Spring a různé knihovny) jako DSL pro psaní byznys logiky. Já bych tedy za DSL nepovažoval ani ty OS, ale přijde mi, že v tomhle je na tom ta Java a OS ve stejné roli.

Jinak nic proti DSL (nebo grafickým nástrojům, které jsou často ekvivalentní k DSL), jen to asi tolik neprožívám jako ty. Přijde mi užitečné část aplikace popsat v DSL či naklikat, popsat nějakou rozhodovací tabulkou stromem atd. ale jednak si myslím, že to (asi) nikdy nenahradí imperativní plnohodnotné programování (ani pro psaní aplikací / byznys logiky) a jednak v tomhle nevidím nějaké hlavní úskalí IT nebo jeho spásu (natož pak v nějakých programátorských komorách). Většina problémů, které v praxi potkávám pramení z toho, že lidi neposlouchali ani v prváku na přednáškách, nečetli ani ty základní knihy a doporučení nebo je ignorují. A nejde o žádné novinky -- spousta těch průšvihů pramení z ignorance metodických doporučení starých deset nebo často i víc let. A pak je spousta problémů IT, které ovšem vznikají mimo IT -- jsou to různé špatně nastavené vztahy mezi zákazníkem a dodavatelem, mezi dodavateli navzájem, vnitrofiremní politika, obchodní politika, mezilidské vztahy a komunikace... A tohle často v projektu napáchá mnohem větší škody než to, jestli jsi něco naprogramoval tak či onak, použil či nepoužil DSL atd.

[deda.jabko]

DSL je nějaký omezený prostor, ve kterém jde (pokud možno deklarativně) popsat, co má program dělat.

DSL = Domain Specific Language, tj. jazyk, ktery je urceny k reseni problemu z nejake konkretni domeny (oblasti). Ten prostor nemusi byt omezeny, ale jazyk by mel umoznovat vyjadrit jednoduse reseny problem. V kontextu teto diskuze me jako ukazkovy priklad napada FoxPro, coz byl jazyk navrzeny pro tvorbu databazi, TUI a reportu. (Ale znal jsem lidi, kteri v tom programovali vsechno, i to, co s databazi nesouviselo, protoze nic jineho neumeli.)

Specialnim pripadem DSL jsou Embedded DSL, kdy mas jeden (obecny) programovaci jazyk a jeho prostredky si vytvoris ten domenovy jazyk. Typicky priklad LINQ, ale treba v LISPu je to predpokladany zpusob tvorby programu. Zacnes jednoduchymi primitivy a postupne budejes jazyk, pro reseni tveho problemu, vcetne ridicich konstrukci, atp. Embedded DSL ale jde vytvorit i v beznych programovacich jazycich, je jen otazkou, co je jeste puvodni jazyk a co uz Embedded DSL. Ale tento problem je spis terminologicky nez realny.

Proč by měl být zásadní rozdíl mezi tím, jestli píšeš v nějakém textovém DSL a tím, kdy totéž (např. datové toky, rozhodovací stromy nebo tabulky) popíšeš v nějakém grafickém nástroji? To má být nějaké elitářství a snaha o to, aby se psal aspoň nějaký kód a vypadalo to aspoň trochu tajemně?

Protoze graficke jazyky jsou sice nazorne, ale maji neuveritelne omezene vyjadrovaci schopnosti. Rozdil je asi jako obrazkova knizka pro deti a normalni knizka. K tomu jeden bugemos.

Co by se asi dalo považovat za DSL, jsou unixové roury a jejich zápis v shellu

Nemyslim. Pro jakou konkretni domenu jsou roury urceny?

Řešení se skládalo z nějaké deklarativní konfigurace a pak z imperativních skritpů, ve kterých byla ta byznys logika. Ale taky bych tomu neříkal DSL -- byl to obecný skriptovací/programovací jazyk, turingovsky kompletní.

Tohle bych za DSL povazoval spis.

Jednak nesouhlasím, protože anotace (a v menší míře i generika) lze považovat za DSL a deklarativní programování. Např. napíšeš metodu obsahující byznys logiku a pak nad ní dáš jednu anotaci a tím ji zpřístupníš po síti jako službu (aniž bys musel imperativně řešit síťovou komunikaci nebo nějaké serializace dat). Totéž platí pro uživatelská práva/role nebo transakce.

Toto bych si nedovolil oznacit za DSL, protoze se v podstate jen jedna o konfiguraci. Konfiguraci presunutou do zdrojovych kodu.

A jednak nevím, v čem by měl být problém? Vadí ti, že můžeš psát byznys logiku ve stejném jazyce, ve kterém se píší frameworky a knihovny?

Nechci mluvit za JS, ale predpokladam, ze mu asi vadi, ze v takovych systemech driv nebo pozdeji dojde k prolinani nizsich a vyssich urovni abstrakce, kdy vysokourovnovy kod, ktery by se mel venovat ciste dane domene a byt strucny a srozumitelny je zapleveleny spoustou low-level veci, jako je prace se seznamy, slovniky, apod. Ale to si myslim je resitelne dobre navrzenym API a vhodnymi restrikcemi at uz na urovni jazyka ci best-practices.

[xkucf03]

Protoze graficke jazyky jsou sice nazorne, ale maji neuveritelne omezene vyjadrovaci schopnosti.

Hranice mezi textovým zápisem a grafickým nástrojem není ostrá -- je tam plynulý přechod. Příklady: zvýrazňování syntaxe, napovídání, kontextové zobrazování dokumentace, prokliky na definici, podbarvení souvisejícího kódu, integrace s verzovacím systémem (podbarvení změněných řádků), zobrazení stromové struktury (třídy, metody, proměnné...), refaktoring, sbalování či skrývání nezajímavých částí kódu, doplnění názvů parametrů do textu u volání metod (ve zdrojáku ten název v místě volání není, ale IDE ti ho tam zobrazuje, abys na první pohled viděl, do kterého parametru která z třeba pěti proměnných předávaných metodě jde), pak různé formy VPL jako Scratch (je to ještě psaní kódu nebo už grafický nástroj?).

Ono totiž kolem těch klíčových slov a konstrukcí jazyka můžeš nakreslit obdélníky nějak to obarvit... a pak pár konstrukcí skryješ a místo nich taháš šipky mezi krabičkami. Úplně nechápu tuhle averzi ke grafickým nástrojům. Samozřejmě, že jich existuje spousta špatných a omezených, ale to neznamená, že takové musí být všechny a že text je vždy lepší. Dobře udělaný grafický nástroj ti dá všechno, co ta textová reprezentace, a navíc se v tom půjde lépe orientovat.

Nemyslim. Pro jakou konkretni domenu jsou roury urceny?

Je otázka, co považuješ za doménu -- jestli to musí být čistě byznysová oblast nebo může být i technická...

Tohle bych za DSL povazoval spis.

...přestože tohle vzniklo v oboru telekomunikací a mělo to původně směrovat SMSky, časem se přišlo na to, že s tím můžeš směrovat i zprávy o účtování těch SMSek (používá se jen jiný protokol, ale princip je stejný), dá se na tom postavit klidně chat (IM server), umí to fungovat jako HTTP nebo SMTP klient (server by v tom šlo napsat taky, kdyby někdo zadal vývoj příslušného modulu)... klidně bys na tom mohl postavit hru, řídit tím továrnu nebo to použít jako celkem klasický aplikační server. A ten jazyk byl obecný programovací jazyk, ve kterém se jinde psaly klidně i desktopové aplikace.

Toto bych si nedovolil oznacit za DSL, protoze se v podstate jen jedna o konfiguraci.

Podle mého to DSL je a nad anotacemi se dá stavět. Ale asi je to jen otázka terminologie.

Nechci mluvit za JS, ale predpokladam, ze mu asi vadi, ze v takovych systemech driv nebo pozdeji dojde k prolinani nizsich a vyssich urovni abstrakce

Jindy se zase setkávám s názorem, že SQL je špatné a že by bylo lepší psát všechno v jednom jazyce. Z tohoto pohledu jsou špatné i regulární výrazy, XPath dotazy a další podobné DSL. Pak je tu spousta webařů, kteří si myslí, že je správné psát klienta i server v jednom jazyce a zavlekli JavaScript na server... tohle úplně nesdílím. Nemám problém s použitím víc jazyků -- pokud to kvůli tomu, že se každý hodí na něco jiného, tak jsem pro, ale nezatahoval bych do systému víc jazyků uměle jen kvůli tomu, abych lidem vyznačil, co je ještě jejich a v čem už se hrabat nemají. A v tom Lispu je to všechno v jednom jazyce (v Lispu), ne? K tomu mi přijde ekvivalentní, když někdo v Javě udělá knihovnu nebo framework a ostatní tento jeho kód pak používají, ale nezasahují do něj.

[deda.jabko]

Ono totiž kolem těch klíčových slov a konstrukcí jazyka můžeš nakreslit obdélníky nějak to obarvit... a pak pár konstrukcí skryješ a místo nich taháš šipky mezi krabičkami. Úplně nechápu tuhle averzi ke grafickým nástrojům.

Jednu dobu se vkladaly velke nadeje do ruznych CASE nastroju a lide zili predstavami, ze od ted se bude programovat v UML. Moc se to nechytlo...

Je otázka, co považuješ za doménu -- jestli to musí být čistě byznysová oblast nebo může být i technická...

Z technickeho pohledu jsou roury prostredek meziprocesove komunikace. Z pohledu jazyka se jedna o prostredek umoznujici skladat mensi logicke celky do vetsich, takze je to ekvivalentni treba volani funkci. Treba lispove jazyky maji threading macros, ktere umoznuji zretezit volani nekolika funkci, takze funguji jako ty roury. Nikdo to nenazyva DSL.

A v tom Lispu je to všechno v jednom jazyce (v Lispu), ne?

Jo, ja s tim problem nemam, je to spis otazka kvality kodu, nez nejakeho separatniho oddeleni.

To, o cemz jsem predpokladal, ze JS mluvi, jsem pred casem zaregistroval v jedne prednasce, kde to dotycny oznacuje jako underabstraction. U Javistu/C# relativne casty problem, ze na vsechno pouziji List, Map, String, Integer jen, aby meli hotovo a nesnazi se vybudovat nejakou rozumnou hierarchii abstrakce, kde pod vrcholem by stal DSL a na vrcholu samotna aplikace. Problem pak byva udrzet se i v te jedne urovni abstakce. V nemale mire k tomuto spatnemu stavu prispiva i obliba ORM a jim vynucenemu anemickemu modelu dat.

[kralyk z abclinuxu]

Jednu dobu se vkladaly velke nadeje do ruznych CASE nastroju a lide zili predstavami, ze od ted se bude programovat v UML. Moc se to nechytlo...

Jo a to je jedině dobře. Z UML mam PTSD ještě dnes. Divím se, že za to nebyl někdo postaven před soud v Haagu.

U Javistu/C# relativne casty problem, ze na vsechno pouziji List, Map, String, Integer jen, aby meli hotovo a nesnazi se vybudovat nejakou rozumnou hierarchii abstrakce, kde pod vrcholem by stal DSL a na vrcholu samotna aplikace.

Ano, a mezi novými jazyky na tuto tradici navazuje Go. IMHO to je minimálně částečně způsobené tlakem firem na srážení nákladů na vývojáře. Viz kecy Roba Pikea:

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

Lidi, co rozumí abstrakcím a mají tendence psát si svá DSL, jsou jednak drazí a jednak mají vastní názory, což je pro korporát blbý.

Oni ale stejně vždycky dříve nebo později vyměknou a ty abstrakce tam dodají, alespoň do nějaké míry, protože bez nich se prostě blbě píše...

[JS1]

Lidi, co rozumí abstrakcím a mají tendence psát si svá DSL, jsou jednak drazí a jednak mají vastní názory, což je pro korporát blbý.

Oni ale stejně vždycky dříve nebo později vyměknou a ty abstrakce tam dodají, alespoň do nějaké míry, protože bez nich se prostě blbě píše...

Ja si myslim, ze korporatu by to prave naopak prospelo. Spis to bude vadit mensim firmam. Velke firmy si mohou dovolit specialisty, a specializace je casto vyhodna. Spis mam za to, ze stavajici stav vyhovuje mnoha programatorum. Kolektivne jsou to totiz oni, kdo ovlada jak se bude obor specializovat (jelikoz se tak deje na zaklade pouzite technologie) a tudiz o tom tak docela nerozhoduje nekdo zvenci (jak by tomu bylo v pripade, kdy se specializace dela na zaklade domenovych znalosti).

[xkucf03]

To je vlastně otázka, jestli mít a) nějakého konzultanta, který rozumí byznysu a zároveň si to naprogramuje v nějakém DSL a pak nějaké nízkoúrovňové programátory, kteří vyvíjejí to DSL, frameworky a další věci. Nebo b) mít analytika, který neprogramuje, maximálně nakreslí nějaké to UML, a pak programátora, který implementuje aplikaci dle analýzy a v případě potřeby by byl schopný sáhnout i do toho frameworku a nižších vrstev.

Nemám na to úplně vyhraněný názor a zřejmě neexistuje jednoznačně lepší varianta pro všechny projekty. Pokud člověk dělá něco menšího, umí programovat a rozumí i tomu byznysu¹, tak může být ten konzultant, který si to pak i napíše, a tím se ušetří spousta režie². Ale vzhledem k tomu, že ten analytik/konzultant tráví spousty času na schůzkách a měl by mít i hodně těch netechnických schopností (jednání s lidmi...) a zároveň by měl umět programovat (byť jen v tom DSL), je poměrně těžké někoho takového najít. V lepším případě najdeš analytika, který umí SQL, zvládá psát dotazy a základy datového modelování. A kdybys náhodou narazil na někoho, kdo to i naprogramuje, tak je otázka, jestli to považovat za výhru. Takového člověka totiž nic nenutí³ ty jeho znalosti a návrh zdokumentovat. A jak známo, člověk je tvor od přírody líný, do toho se blíží termín a projekťák nechce navyšovat výdaje nějakým dodatečným psaním dokumentace... Takže ve výsledku jsi (jako ten, kdo to platí) závislý na tom jednom člověku a znalostech, které má v hlavě a které si může kdykoli odnést.

_{[1] což jsou typicky projekty, které děláš pro sebe, máš na nich nějaký osobní zájem -- zatímco v práci děláš z velké části pro někoho a on platí za tvůj čas, neřešíš primárně svůj problém
[2] předávání znalosti od jednoho člověka k druhému -- což má ale zase stinnou stránku v tom, že ta znalost je jen v hlavě toho člověka a není nikde zdokumentovaná, aby ji mohl použít někdo třetí, aby k něčemu byla i v jiném čase nebo prostoru
[3] ano, dokumentace se dá odfláknout i v týmu, kde je analytik a programátor, ale tam se aspoň pozorováním dá zjistit, že je něco v nepořádku -- programátor chodí moc často za analytikem, nadává na něj, hádají se}

[xvasek]

Máš pravdu, našel jsem se, popis je přesný. Jenom s tou dokumentací... To není o lenosti, já dokumentaci umím krásnou a dělám ji s radostí kdykoli k tomu mám prostor. Dokumentaci většinou škrtá spíš zákazník, aby to "bylo levnější", popřípadě někdo, kdo ten projekt vede, aby to "bylo rychleji", ale analytik / programátor sám od sebe málokdy, takže bych neřekl, že se situace nějak zásadně liší od stavu, kdy jsou ty role rozdělené.

Na nedostatečné dokumentaci stejně samostatný analytikoprogramátor pohoří u první složitější věci, kterou má zakazník převzít, takže poučen z tohoto nezdaru už to v rámci rozvoje osobnosti nebude vícekrát opakovat. Ledaže by se v něčem babral dlohodobě několik let, aniž by to pořádně předal, to jde občas taky vidět.

[JS1]

To je vlastně otázka, jestli mít a) nějakého konzultanta, který rozumí byznysu a zároveň si to naprogramuje v nějakém DSL a pak nějaké nízkoúrovňové programátory, kteří vyvíjejí to DSL, frameworky a další věci. Nebo b) mít analytika, který neprogramuje, maximálně nakreslí nějaké to UML, a pak programátora, který implementuje aplikaci dle analýzy a v případě potřeby by byl schopný sáhnout i do toho frameworku a nižších vrstev.

V tomhle mam dost jasno - to prvni je lepsi. Protoze je vec, kterou ti UML neda - UML ti nerekne, ze to co chces, je absurdni, nelogicky protimluv.

Rika ti neco jmeno Vladimir Voevodsky? To byl vynikajici matematik (dostal Fieldsovu medaili), ktery jednoho dne zjistil, ze v jednom z jeho starych dukazu je zavazna chyba. Proslo to peer review, vsichni to pouzivali.. a bylo to spatne. Tak se rozhodl, ze to tak dal nejde, a ze bude vsechna svoje dalsi matematicka tvrzeni a dukazy zapisovat ve strojove citelne forme, aby to mohl pocitac zkontrolovat na korektnost.

A ja myslim, ze jeho zaver byl naprosto spravny. Meli bychom usilovat o totez, aby vsechno, co delame, bylo strojove citelne a kontrolovatelne minimalne na to, zda v tom neni logicky rozpor.

Nez jsem se zacal zabyvat P=NP, uvazoval jsem nad teorii neuplnych specifikaci (jde o jistou aplikaci teorie informace na specifikace deterministickych algoritmu). Ale bez moznosti resit efektivne problem splnitelnosti je zda se ta (zatim hypoteticka) teorie pro prakticke pouziti prilis slaba (proto mimo jine muj zajem o P=NP). Protoze musime nejak predpokladat, ze je ta neuplna specifikace logicky korektni, a to je prilis silny predpoklad.

[xkucf03]

Já to nechci rozporovat, vlastně se mi ten tvůj přístup líbí. Jen přemýšlím, jak to (v širším měřítku) prosadit v praxi. A myslím tím běžné firmy, ne nějaké akademické pokusy, nebo výjimečné firmy, kde se sejde pár hodně nadprůměrných lidí. Má to vlastně být pro všechny, i pro takové průměrné firmy, nebo ne?

Protoze je vec, kterou ti UML neda - UML ti nerekne, ze to co chces, je absurdni, nelogicky protimluv.

BTW: existují různé snahy o spustitelné UML nebo ten BPEL... Pak jsou tu CASE nástroje, což nejsou jen hloupá kreslítka diagramů, ale má to i různá pravidla, která model kontrolují a vyhodí ti různá varování nebo chyby, že jsi vymyslel blbost nebo že ten nástroj/model používáš nesprávně. V podstatě si to můžeš představit jako DSL a jeho kompilátor, který vypisuje chyby a varování. Ale to jen tak naokraj.

Meli bychom usilovat o totez, aby vsechno, co delame, bylo strojove citelne a kontrolovatelne minimalne na to, zda v tom neni logicky rozpor.

S tímhle souhlasím a snažím se to prosazovat. Ale má to různá úskalí -- např. to, že analytik těm nástrojům nerozumí, neumí je používat a neumí je vytvořit, vlastně ani neví, že existují nebo můžou existovat. Projektový nebo produktový manažer s tím taky nepřijde, protože má stejný problém jako analytici a navíc se soustředí na jiné věci. Takže ta iniciativa přichází od programátora, který je schopný ten nástroj vyrobit nebo najít nějaký vhodný existující. A tam jsi v poměrně nevděčné roli, protože fušuješ analytikům do jejich práce a říkáš jim, že to dělají blbě a měli by to dělat jinak. A taky to vypadá, jako by ses snažil svoji práci přehodit na někoho jiného ("my mu to dáme ve strojově čitelné podobě a on si nad tím jen pustí nějaký skript a bude mít hotovo").

Dovedu si představit, že nějaký osvícený inženýr založí vlastní firmu a postupně do ní bude nabírat lidi a zpracuje si je, předá jim svoji vizi a naučí je myslet jako on. Pak mají šanci (pokud jim nedojdou prachy a nerozhádají se) dosáhnout toho, o čem tu píšeš.

Ale máš představu, jak tohle prosadit v existující firmě, kde jsou role už nějak rozdělené, každý si tak trochu jede to svoje, jak je zvyklý, máš tam běžící projekty, servisní smlouvy, spousty softwaru psaného "tím starým způsobem"?

Co si myslíš třeba o takovém Swagger Editoru (OpenAPI)? Je schůdné, aby tenhle nástroj používal byznysový analytik a definoval v tom rozhraní mezi systémy? Nebo ten nástroj bude nakonec obsluhovat zase nějaký programátor? A to je jen takový malý krůček -- strojově čitelné HTTP API (není tam ani strojově čitelný popis vnitřní logiky -- tak daleko to vůbec není). Ono WSDL/XSD taky většinou píší programátoři... trochu se obávám, že tahle reinkarnace téhož (OpenAPI) dopadne stejně... ale třeba ne. Asi nejblíž k byznysu má to SQL (ale zdaleka ne ve všech firmách -- někde to analytici berou jako čistě technickou věc, kterou se oni zabývat nebudou).

Fakt to nepíšu, abych prudil nebo abych zpochybňoval, co jsi řekl. Pokud poradíš, jak na to, tak budu rád a třeba to někdy použiji v praxi. Zatím mi ale přijde, že to jde jen tak, že začneš na zelené louce. Nebo po malých krůčcích ve stávajících firmách, ale tam vidím prostor pro zlepšení trochu někde jinde -- nejde až tak o to chybějící DSL, ale o to, že se dělají chyby v daleko banálnějších věcech a nedodržují se často ani základní doporučení na úrovni prvního ročníku SW inženýrství na ekonomce :-) Tzn. to úzké hrdlo, které je třeba optimalizovat, je IMHO jinde než v DSL (i když samozřejmě jeden z těch kroků může být, že se některé věci předělají do strojově čitelné podoby -- pokud to jde nějak bez velkých nákladů a problémů zapracovat).

Taky je otázka, jak alokovat ty lidi a kde by měli sedět. Jen velké firmy by si mohly dovolit zaměstnat ty nízkoúrovňové programátory, kteří by jim rozvíjeli to DSL. Většinou by to bylo spíš tak, že se ten nástroj jednou napíše a pak dlouho používá -- jen sem tam nějaká změna. Co by ten programátor dělal mezi tím? To by tedy znamenalo tento vývoj outsourcovat? Dodávala by to nějaká externí softwarová firma? Nebo bys na to najímal známé odborníky na volné noze? Jak by byly stavěné ty smlouvy na vývoj DSL (nebo nějakých nástrojů)? Kdo by byl schopný na straně zákazníka napsat zadávací dokumentaci a specifikovat požadavky? Jak by se vyhodnotilo, že je ten dodaný abstraktní nástroj/DSL kvalitní? Dnešní stav rozhodně není ideální, ale když se dodávají celé aplikace (tzn. není to rozdělené mezi dva subjekty, kde jeden tvoří nástroj a druhý pomocí nástroje aplikaci), tak se dá snáz specifikovat zadání a snáz se dá vyhodnotit kvalita a rozhodnout, jestli proplatit fakturu nebo si stěžovat a chtít ještě nějakou opravu/dodělávku.

BTW: Máš nějaké příklady dobrých DSL nebo nástrojů pro jednotlivé obory, které bys mohl dát za vzor?

Na téhle diskusi je zajímavé, že většinou jsem já ten idealista, který říká, jak by to mělo být správně, a preferuje dlouhodobější cíle, zatímco ostatní mu oponují a říkají, že teď na to nejsou peníze/čas a musí se to nějak udělat s tím, co máme, a investovat do rozvoje se bude až příště. Tak tady jsem jakoby v té opačné roli a hájím ten druhý názor (i když to tak ve skutečnosti není a chci víceméně to, co ty -- jen bych od tebe rád slyšel, jak se do toho ideálního stavu v praxi dostat -- ne jen, jak ten ideální stav vypadá).

[JS1]

Uvazoval jsem o tom (proto delsi odezva).. Nejsem si jisty, jestli ja jsem dostatecne kvalifikovany na to, abych ti dal dobrou odpoved.

Ale historicky za prvni takovy uspesny pokus povazuji COBOL. Na hodne starych pocitacich byla I/O manipulace s daty slozita, a COBOL tohle abstrahoval zpusobem vhodnym pro business aplikace.

Pozdeji vznikly ruzne 4GL jazyky. Hodne z tech, co jsou na te strance, se stale pouziva.. Ale hlavni problem je, ze jsou to obvykle prehnane drahe a uzavrene ekosystemy, takze si to kazdy radsi patla na zelene louce.

Ja mam pochybnost, ze muze vzniknout rozsireny opensource (business) 4GL, prestoze si myslim, ze by v tom byl velky benefit. Jak uz jsem trochu naznacil, jeden z problemu je v tom, ze programatori proste nechteji byt vnimani jako "COBOL programatori" (dneska bychom asi rekli "lepici"), a to plati i pro 4GL. Je to myslim do znacne miry egoismus, ktery brani programatorum sireji akceptovat 4GL. Castecne je ten duvod na druhe strane - analytici nechteji nic programovat, protoze jsou prilis inteligentni na to, aby chteli mit zodpovednost za to, ze jejich "analyza" pak v praxi nefunguje .

Jinak ty embedded systemy, co tu nekdo zminoval, to je dobry priklad DSL.

[okbob]

Vzestup a pád 4GL jazyků je hodně poučný. Pokud programátor dokázal zadání přetransformovat, tak aby bylo ve shodě s filozofií vývojového prostředí, tak velice efektivně a velice rychle navrhl kvalitní aplikaci. Nicméně pokud zadání vybočovalo z možností vývojového prostředí, tak vývojář končil a nic moc udělat nemohl. Modifikovat 4GL nástroj v 4GL nástroji dost dobře nejde. Nepotkal jsem programátory, kteří by se styděli za to, že programovali ve FoxPru nebo v čemkoliv podobném. Na větších projektech to ale moc nefungovalo. 4GL nástroje byly moderní v době svého vzniku, ale hodně rychle stárly. U generických jazyků se jenom vyměnila knihovna, a mohlo se pokračovat dál.

[JS1]

Nesouhlasim, ze to co uvadis, jsou nejak inherentne problemy 4GL jazyku.

Nicméně pokud zadání vybočovalo z možností vývojového prostředí, tak vývojář končil a nic moc udělat nemohl.

4GL nastroje starnou predevsim proto, protoze jsou komercni a firmy nemaji dost zajmu je udrzovat; kdyby byly open source, tak by se s nim neco dalo delat. Stejny problem postihl komercni Unixy, komercni Lispy,..

Modifikovat 4GL nástroj v 4GL nástroji dost dobře nejde.

Prave to by byla role SW inzenyru, udrzovat infrastrukturu potrebnou pro aplikace v tom jazyce, jak jsem psal vys. Ostatne, nefunguje neco podobneho i u SQL? SQL je prece taky 4GL jazyk.

Nepotkal jsem programátory, kteří by se styděli za to, že programovali ve FoxPru nebo v čemkoliv podobném.

Nejde o to, ze by se stydeli tito, jde o to, ze nova generace se nechce ucit 4GL jazyk, protoze to neni "sexy". Vidis to na NoSQL. Proste mnoho lidi ma dojem, ze kdo nedela infrastrukturu nebo OS, ale jen business aplikace, neni dost dobry. Proto si myslim, ze cely obor potrebuje svoji vlastni komoru, ktera by lidem v nem ukazala, podivejte, nezalezi primarne na tom, jaky mate dopad, nepanikarte, pro vetsinu lidi je to jen job.

U generických jazyků se jenom vyměnila knihovna, a mohlo se pokračovat dál.

To nikdy nebyla pravda, napr. zmenit aplikaci z WS do RESTu neni jen o vymene knihovny. 3GL jazyky jsou v tomhle smeru spis obtizneji nahraditelne, protoze je malokdy jasne, kde vlastne zacina a konci business logika.

Zatimco (dobre navrzene) 4GL se daji interpretovat ruzne, protoze jsou znacne nezavisle na infrastrukture, a tudiz jsou snaze prenositelne.

[okbob]

Kupodivu open source 4GL produkty téměř nevznikly, nebo pokud vznikly, tak živoří. Proč?

A i kdyby byly open source, docela pochybuji, že by je někdo rozvíjel - jakmile složitost produktu přesáhne určitou míru, tak i pokročilejší uživatelé zvládnou maximálně jednodušší bugfixy. Pro rozvoj jsou nutní fulltime vývojáři, a z hlediska firmy, která by potenciálně 4GL jazyk používala, to je určitě mimo core byznys, takže není moc reálné, že by takové vývojáře platila. Co se týče úpadku, tak se 4GL nástroje neliší od komerčních Unixů - jedná se o komplexní sw, kde vývoj není triviální, a pokud vám klesnou marže - např. už nedokážete tak draho prodávat hw, tak nemáte peníze na zafinancování vývoje sw. Čím je hw nebo sw specializovanější, tím musíte mít vyšší marže, abyste si vydělal na provoz. Naopak čím je sw obecnější, tím máte větší šanci si vydělat, nebo potkat někoho, kdo se s Vámi dělí o náklady na vývoj - což je případ Linuxu, Postgresu.

SQL má několik výhod - existuje ANSI/SQL - takže je tam určitá přenositelnost, navíc je tam ohromná penetrace. Navíc se SQL poměrně dobře integruje s 3GL jazyky. Nicméně i přes relativně masivní nasazení z desítek SQL databází zůstalo několik málo open source, a několik málo komerčních. Vývoj je natolik drahý, že bez tisíců platících uživatelů to neufinancujete.A to ještě SQL je relativně obecným nástrojem - nemá žádnou vazbu na prezentaci, operační systém nebo aplikační doménu.

Problém je ta specializace - čím efektivnější pro určitou doménu má jazyk, platforma být, tím musí být specializovanější - většinou tyto jazyky dobře poslouží svému účelu, ale po 10 letech firmy už nemají motivaci na rozvoj, bo nic víc nepotřebují, ale je pro ně drahé cokoliv v těchto prostředích dělat, jelikož téměř neexistuje čerstvá krev, která by nahrazovala nové vývojáře. A že by si korporát zaplatil low level vývojáře, kteří by třeba udělali portaci, aktualizaci .. tak minimálně v ČR jsem na žádnou takovou firmu nenarazil. Zvlášť korporát chce investovat jen do svého sw, a ani náhodou do cizího produktu.

[xkucf03]

4GL nastroje starnou predevsim proto, protoze jsou komercni a firmy nemaji dost zajmu je udrzovat; kdyby byly open source, tak by se s nim neco dalo delat.

Našel jsem např. EntireJ, to je svobodný software.

Proste mnoho lidi ma dojem, ze kdo nedela infrastrukturu nebo OS, ale jen business aplikace, neni dost dobry.

S tím se setkávám poměrně často. Alespoň v komentářích na internetu. Kdybych se měl řídit jimi, tak to abych si pomalu připadal méněcenný, že dělám "jen tu Javu" a nepíšu v Haskellu nebo aspoň nepřispívám do Jádra nízkoúrovňovým céčkovým kódem

Nicméně vybral jsem si to dobrovolně a jsem s touto volbou spokojený. Trochu toho céčka (nebo spíš C++) ve svých projektech taky používám a v důchodu možná bude čas i na ten Haskell :-) ale co se týče práce pro zákazníky, tam vede ta Java a SQL. Jde o to, že takových zakázek je plno a člověk má víceméně jistotu, že ta práce bude, kdykoli ji potřebuje. Můžu si dát klidně půl roku nebo rok prázdniny a pak naskočit na nějaký projekt pro někoho jiného. Oproti tomu, kdybych dělal v ne tolik obecném jazyce/nástroji (nedejbože proprietárním), tak bych se musel držet té jedné firmy, která ho používá, a byl bych na ní závislý. To by např. všechny banky v Praze musely používat stejné DSL, aby měl člověk jakž takž jistotu a svobodu, ale i tak by byl vázaný na obor bankovnictví.

SQL je taky dostatečně obecné, není oborově závislé -- když umíš psát dobře SELECTy, tak je můžeš psát pro kohokoli.

Proto si myslim, ze cely obor potrebuje svoji vlastni komoru, ktera by lidem v nem ukazala, podivejte, nezalezi primarne na tom, jaky mate dopad, nepanikarte, pro vetsinu lidi je to jen job.

Existují různé spolky, lidi se sdružují, buď na základě filosofie (FSF, EFF, FSFE) nebo kolem operačních či databázových systémů, nebo kolem jazyků... scházejí se, dělají přednášky. Pak jsou tu různé konference (např. OpenAlt :-), kde se setkají lidi napříč jazyky, nebo programátoři se správci a uživateli.

V nějaké obecné programátorské komoře nevidím moc smysl -- co by to nabídlo oproti stávajícím organizacím? Navíc to zavání nějakým lobbyismem a NGOismem (politika, legislativa, omezování současné svobody podnikání...). Co se týče kvalifikace, od toho je zase vysokoškolské studium -- jsou firmy, které vyžadují magisterský titul z nějaké slušné školy. Nebo pak certifikace pro jednotlivé jazyky, distribuce, metodiky atd.

Kdybys vytvořil nějaké skvělé DSL, tak bys kolem toho asi udělal nadaci, pořádal konference, placená školení a vydával certifikace. Firmy by si pak vybíraly odborníky na základě té tvé certifikace. Nicméně není to programátorská komora -- je to vázané na to jedno DSL nebo metodiku.

Ty certifikace a různá školení jsou dobrý způsob jak zajistit, aby tekly potřebné peníze k těm organizacím, které vyvíjejí ten infrastrukturní kód. Chtělo by to, aby se stalo (více) obvyklým, že ti lidé jsou certifikovaní, chodí na školení, že si firmy platí podporu frameworků, které používají... tohle můžou vynucovat zase certifikace a audity těch celých firem. Měli by to vyžadovat zákazníci -- např. stylem: zaplatíme vám tolik milionů za aplikaci, ale nechceme, abyste to bastlili jen tak na koleně, chceme, abyste měli X certifikovaných lidí, abyste si platili podporu od vývojářů toho svobodného softwaru, na kterém to stavíte, aby díky tomu vaši vývojáři měli krytá záda pro případ, že nebudou něco umět nebo něco nebude fungovat.

Na druhou stranu by to ale stále mělo být dobrovolné resp. vycházející z reálných potřeb. Protože jakmile se z toho stane nějaká formální povinnost vynucená např. zákonem a ty organizace mají jisté příjmy de facto za nic, tak to má tendenci k tomu, že tam budou lidi sedět v nějakých komisích, budou za to brát peníze, ale reálný výstup (užitečné nové verze) z toho nebude žádný.

To nikdy nebyla pravda, napr. zmenit aplikaci z WS do RESTu neni jen o vymene knihovny.

Tam jde ale o zásadní změnu pohledu na věc. Zatímco SOAP je orientovaný na služby/procedury, v RESTu jsou na prvním místě zdroje (resources, entity). Jde o to, jestli chceš takto radikálně změnit ten pohled -- pokud ano, tak tu aplikaci musíš přepsat dost od základu, není to jen o změně rozhraní. Spousta lidí a firem tuto změnu nepobrala nebo nepřijala a REST používají víceméně jen proto, že mají pocit, že je moderní a že dneska musí být všechno v RESTu. Ale v zásadě jsou pořád orientovaní na služby/procedury -- jen tato RPC volání balí do HTTP a JSONu a říkají tomu REST. Pokud k tomu přistupuješ takto, tak v podstatě stačí jen vyměnit tu knihovnu -- např. v Javě nad ty metody v controlleru dáš jiné anotace a jinak to může zůstat stejné. Nebo tam přidáš nové controllery a zachováš jak původní SOAP rozhraní, tak přidáš nové "REST" rozhraní.

Často ta změna ani nedává smysl -- protože daná úloha je ze své podstaty RPC a systém poskytuje spíše služby než, že by pracoval s nějakými zdroji.

Navíc se tím lidi často připravili o strojově čitelné API -- zatímco pro SOAP/WSDL/XSD měli už před mnoha lety dostatek nástrojů pro práci se strojově čitelným popisem rozhraní, různé generátory, simulátory, validátory... v případě RESTu dlouho nic z toho neexistovalo a dělalo se vše ručně. Dneska je aspoň ten Swagger resp. OpenAPI, ale stále to není ono, pořád to nedosahuje té úrovně, jakou mělo WSDL, i když složitostí to ten "starý" přístup už možná dohnalo nebo i předehnalo. A spousta firem to pořád nepoužívá a dělají to ručně -- napíší kód, ten publikují jako REST API (to celkem automatizované je), pak k tomu napíší ručně dokumentaci a z této dokumentace to lidi na straně klienta opisují a dělají si svoje vlastní třídy nebo svůj vlastní kód, který by měl (pokud při opisování nikdo neudělal chybu) pasovat na to serverové rozhraní. V horším případě pořádná dokumentace k dispozici není a jsou jen nějaké útržkovité příklady volání, podle kterých máš toho klienta napsat.

3GL jazyky jsou v tomhle smeru spis obtizneji nahraditelne, protoze je malokdy jasne, kde vlastne zacina a konci business logika.

Zrovna u těch podnikových aplikací je víceméně oborový standard ta Java -- a to buď EE nebo Spring (často se to prolíná) a k tomu SQL nebo ORM (JPA). A nepřijde mi, že by to bylo nějak moc nízkoúrovňové. Jsou zavedené návrhové vzory, spousta věcí se řeší deklarativně pomocí anotací. A do vnitřků těch metod píšeš víceméně tu byznys logiku s minimem balastu. Pokud tohle (EE/Spring) nechceš považovat z DSL, tak si minimálně troufám tvrdit, že to funkci DSL plní.

Je otázka, jestli je tu prostor pro nějaké jiné (skutečné) DSL a jestli by lidi měli zájem na něj přejít.

BTW: Celkem dlouho jsem teď používal integrační framework Apache Camel, který právě ten DSL přístup prosazuje. Některé věci tam jdou zázračně jednoduše a elegantně. Často je ten výsledek na pár řádků. Problém ale je, jak se k těm pár řádkům dobrat. Někdy to vymyslíš nebo aspoň najdeš příklad, který řeší to, co potřebuješ, a máš to za chvilku, a jindy nad tím můžeš dumat tři dny a celou dobu nemáš jistotu, jestli se výsledku dobereš nebo ne. Nepříjemné na tom je, že dopředu moc nevíš, jestli řešením budou tři řádky nebo tři dny... (nebo tři řádky pracně vykřesané za tři dny). Oproti tomu v obecném jazyce jako je Java, jsem schopný dát ten odhad s mnohem větší přesností. A i když tam může být něco pracnější (často ale není), tak je to mnohem víc předvídatelné. A zákazníkovi je nakonec celkem jedno, jestli se programováním strávily dva dny nebo tři -- mnohem důležitější je, že když řekneš, že to za tři dny bude, aby to opravdu bylo, aby ten vývojový proces byl spolehlivý a plynulý. Ona ta celková bilance u Camelu není nějak špatná a v zásadě to funguje, ale někdy je to o nervy.

Nevím, jak moc je to obecná vlastnost DSL nebo zda se to týká jen konkrétních implementací, ale trochu se obávám, že to s DSL něco společného mít bude. Že se ti u nich častěji může stát to, že když je používáš tak, jak jejich autor předpokládal (a pro jaké případy užití připravil dokumentaci a příklady), tak to jde hladce a předvídatelným tempem, zatímco v jiných případech můžeš narazit na nečekané problémy a rozptyl těch odhadů bude mnohem větší než u obecného programovacího jazyka.

Naopak dobrým příkladem je podle mého SQL, protože tam máš relativně jistotu, že ty SELECTy půjdou napsat. A pokud ne, tak je to většinou buď zpraseným datovým modelem (to se dá zjistit předem) nebo tím, že řešená úloha je z principu složitá a trvala by dlouho, i kdyby se řešila pomocí jiného nástroje.

Zatimco (dobre navrzene) 4GL se daji interpretovat ruzne, protoze jsou znacne nezavisle na infrastrukture, a tudiz jsou snaze prenositelne.

Ano, tohle je pozitivum.

3GL jazyky jsou v tomhle smeru spis obtizneji nahraditelne, protoze je malokdy jasne, kde vlastne zacina a konci business logika.

Na druhou stranu: když máš infrastrukturní kód a byznys logiku psanou v jednom programovacím jazyce, tak ten programátor, který psal byznys logiku, může časem začít přispívat do těch frameworků -- např. v něm najde chybu a společně s jejím hlášením může poslat rovnou patch, protože tomu jazyku rozumí. Např. v Javě je přechod z byznys logiky do infrastrukturního kódu jeden proklik v IDE a je to psané v jednom jazyce. Rovněž to taky vychová řadu odborníků, kteří jsou schopní ty frameworky rozvíjet, takže jen tak neumřou (ty frameworky). Když budeš potřebovat lidi na vývoj nové verze frameworku/infrastruktury, tak přetáhneš pár těch, kteří do té doby nad tímto frameworkem psali byznys logiku, trochu je zaškolíš a můžou pracovat. Tedy ne že by to bylo až tak jednoduché, ale určitě je to jednodušší, než když to budou úplně jiné jazyky a ty role budou striktně oddělené. Např. bych mohl jít přispívat do standardní knihovny Javy -- ale naopak bych si netroufal jít přispívat do PostgreSQL jen na základě toho, že umím psát SELECTy. Stejně tak přispívat do Jádra považuji za výrazně obtížnější, přestože ho každý den používám.

Opačný extrém je třeba JavaScript, kde spousta lidí mastila jen nějaké skriptování formulářů v prohlížeči a najednou začali psát infrastrukturní kód a knihovny pro ostatní... kvalita tomu pak odpovídá. Ale pořád mi přijde lepší, mít velké množství vývojářů, ze kterých si vybereš ty schopné, než se potýkat s nedostatkem vývojářů a muset si vychovávat vlastní -- protože jinak ti ten infrastrukturní kód (framework, DSL atd.) taky třeba umře, protože ho nebude mít kdo vyvíjet... a v důsledku absence nových funkcí a oprav ti postupně začnou odpadávat i ti uživatelé.

Odkud by se tedy měli brát ti inženýři tvořící infrastrukturní kód? Na čem by měli získat praxi a zkušenosti? Nebo by měla stačit jen teoretická průprava ze školy?

Kromě toho spousta nových a dobrých věcí vzniká živelně, po večerech a o víkendech... a až postupně to dospěje do stadia, že je to schopné uživit nějaké vývojáře naplno. A v těch počátcích je právě snazší vzít jazyk, kterým se člověk běžně živí a se kterým má praxi. Tzn. já si můžu psát celkem snadno vlastní knihovny nebo infrastrukturní nástroje v Javě, ale učit se do toho ještě jiný jazyk člověka výrazně zpomaluje. Mimochodem, to ale teď dělám a píšu jeden nástroj (resp. referenční implementaci určitého frameworku/metodiky?) v C++. Jde to a na jednu stranu mě baví, že je to zase něco nového, ale na druhou stranu to jde výrazně pomaleji než v jazyce, který znám. A taky je na tom dobře vidět, jak náročné je psát ten infrastrukturní kód (navrhnout a udržet stabilní API a ABI atd.).

[deda.jabko]

Navíc se tím lidi často připravili o strojově čitelné API -- zatímco pro SOAP/WSDL/XSD měli už před mnoha lety dostatek nástrojů pro práci se strojově čitelným popisem rozhraní, různé generátory, simulátory, validátory... v případě RESTu dlouho nic z toho neexistovalo a dělalo se vše ručně.

SOAP, WSDL a spol. jsou ukazkovy priklad, jak konci design by committee. Je hezke, ze pro tyto standardy existuji nastroje, ale je to spise z nouze ctnost, protoze ty standardy jsou natolik komplexni, ze bez podpurnych nastroju ani pouzivat nejdou. Naproti tomu RESTful API je takova vzpoura zdola vuci nabubrelosti techto standardu a navrat k principu KISS. Vzhledem k rozsirenosti SOAP a RESTful API jde videt, co programatori chteji.

[xkucf03]

SOAP, WSDL a spol. jsou ukazkovy priklad, jak konci design by committee.

Dospělo to poněkud obludných rozměrů -- ale to jsou různé nadstavby, které nemusíš používat. Pokud navrhneš základní webovou službu, tak je to jednoduché WSDL popisující služby/procedury a potom jednoduché XSD popisující datové struktury (požadavky a odpovědi).

Naproti tomu RESTful API je takova vzpoura zdola vuci nabubrelosti techto standardu a navrat k principu KISS. Vzhledem k rozsirenosti SOAP a RESTful API jde videt, co programatori chteji.

Na začátku tahle myšlenka byla. Jenže se podívej, kam to dopracovali. Ta komplexita dosáhla úrovně SOAP webových služeb a někdy ji asi i překročila. Např. do toho zapracovali i autentizační tokeny, takže to není ani bezestavové. Přišli na to, že jsou potřeba jmenné prostory, jenže ty v JSONu nejsou, tak tam začali mastit nějaké prefixy... Generování tříd ze strojově čitelné definice rozhraní mi přijde náročnější než u WSDL (schválně si to chci někdy změřit, kolik kódu do toho vstupuje...). Znovu se vynalézá kolo.

Připadá mi to takové... "Mysleli jsme to dobře, ale dopadlo to jako vždycky" :-)

[deda.jabko]

Pokud navrhneš základní webovou službu, tak je to jednoduché WSDL popisující služby/procedury a potom jednoduché XSD popisující datové struktury (požadavky a odpovědi).

Dobre. A dokazes to udelat z hlavy, treba v Bashi?

Jenže se podívej, kam to dopracovali. Ta komplexita dosáhla úrovně SOAP webových služeb

Mozna nekde. Sluzby, ktere jsem pouzival, mely API/protokol jednoduchy jako kafemlejnek a daly se bez problemu pouzit treba z Bashe, napr. pro debugovani. Chapu, muzou existovat sluzby, ktere zavadi dalsi komplexitu, ktera je na urovni treba SOAP, hlavni rozdil je v tom, ze u SOAP tu komplexitu mas i pro trivialni pripady, u REST jen u blbe navrzeneho rozhrani.

Generování tříd ze strojově čitelné definice rozhraní mi přijde náročnější než u WSDL

For je v tom, ze u REST se muzes obejit bez nejakeho generovani trid. To v pripade WS je cira utopie. Z meho pohledu je to vyhoda, protoze se ti v kodu neobjevuji chuchvalce vygenerovaneho kodu a mas uplnou kontrolu nad tim, co se jak deje a proc.

Připadá mi to takové... "Mysleli jsme to dobře, ale dopadlo to jako vždycky"

V praxi se ale naprosto bezne pouzivaji mene dokonala reseni, protoze jejich pouziti je snazsi nez u reseni, ktera jsou dokonalejsi.

Napriklad si vezmi regularni vyrazy. Jejich vyjadrovaci schopnosti jsou znacne omezene, nerozparsujes s nimi libovolny mirne slozitejsi format dat. Na jejich misto by sel pouzit libovolny nastroj na generovani parseru bezkontextovych gramatik typu Bison/ANTLR, ktery toho umi podstatne vic. Presto v rade situaci radsi sahnes po regularnich vyrazech, protoze jsou proste jednodussi na pouziti. Podobne je to s REST a WS.

[xkucf03]

Dobre. A dokazes to udelat z hlavy, treba v Bashi?

Zhruba stejně, jako kdybych měl na základě Swagger specifikace volat REST API. V obou případech je to POST (v případě RESTu i jiné operace) na nějaké URL s nějakými HTTP hlavičkami a s nějakým tělem, do kterého se jednou píší ostré závorky a jindy složené. Provoláš to přes curl nebo wget.

Poslepovat tu zprávu je trochu opruz v obou případech -- jak XML, tak JSON bys měl escapovat. To uděláš buď sedem nebo se na to vykašleš (v případě nějakého ručního testování a ad-hoc provolávání, kde máš data pod kontrolou a např. víš, že do šablony dosazuješ pouze čísla).

Někdy to takhle používám pro ruční provolávání a nějaké poloautomatické testy.

Pak k tomu mám dva skripty, které mi naformátují a obarví výstup:

formátuj-xml.sh:

#!/bin/bash

sed ':a;N;$!ba;s/\n//g' | xmllint --format - | pygmentize -l xml

formátuj-json.sh:

#!/bin/bash

python -m json.tool | pygmentize -l json

Složitost při ručním provolávání na základě specifikace mi přijde stejná. Pokud máš místo specifikace příklady, tak je jen upravíš a provoláš, takže je to zase stejné.

Chapu, muzou existovat sluzby, ktere zavadi dalsi komplexitu, ktera je na urovni treba SOAP, hlavni rozdil je v tom, ze u SOAP tu komplexitu mas i pro trivialni pripady, u REST jen u blbe navrzeneho rozhrani.

Nemyslím si. Když navrhuji WSDL/SOAP službu, tak to dělám úplně jednoduše, klidně si to můžeš volat v Bashi z curlu, je to jednoduché RPC, pár služeb, kde každá má nějaký požadavek, odpověď a alternativně chybovou odpověď, pokud je to potřeba.

Že někdo dokáže zprasit WSDL/SOAP takovým způsobem, že tam máš parametry vždy pojmenované arg0, arg1 atd. a arg0 je textového typu, kde ten text obsahuje příkazy/hodnoty typu klíč=hodnota oddělené mezerou a odpověď pak obsahuje vnořené XML (tzn. escapované, jeho formát není specifikovaný ve WSDL/XSD té služby, stejně jako ty klíče/příkazy v požadavku), tak to už je problém konkrétního prasiče, nikoli té technologie (mimochodem tohle je reálný příklad API jednoho produktu jedné nejmenované korporace). V JSONu jsou lidi schopní dělat to samé, zabalí do jednoho atributu třeba hodnoty oddělené čárkou nebo mezerou, nebo další (escapovaný) JSON nebo třeba JSON či jiný formát v Base64. Nebo z toho cítíš, že ve skutečnosti nechtějí dělat REST a pracovat se zdroji, ale že chtějí dělat RPC -- tak prostě dělají RPC, v URL je název služby, všechno je POST a i to, co je logicky GET má tělo, ve kterém je třeba jeden atribut (nějaké ID). Je smutné, jaké dogma se z toho stalo, a že dneska "musí REST dělat každý", aby nevypadal "zpátečnicky" -- i když tento model/styl na jeho úkol nepasuje, je nepřirozený a daleko víc by se hodilo RPC. Spousta lidí/týmů se tak vrátila někam do počítačového pravěku, připravila se o šikovné nástroje a tvářila se přitom, jaký dělají pokrok... Uvidíme, co přinese s GraphQL a jak se k tomu lidi v reálných projektech postaví. Dost možná přibudou jen další mapovací vrstvy a frameworky a stoupne komplexita.

For je v tom, ze u REST se muzes obejit bez nejakeho generovani trid. To v pripade WS je cira utopie.

Není. Klidně můžeš XML požadavku postavit dynamicky nějakou knihovnou nebo poslepovat z kusů textu. Odpověď pak můžeš zpracovat třeba XPath dotazy nebo SaX parserem. Nikdo tě nenutí si ty třídy generovat. Ostatně v tom bashi/curlu taky žádné třídy nemáš a funguje ti to.

Vtip je v tom, že vygenerované třídy ti dávají typovou kontrolu a zbavují tě nutnosti koukat pořád do dokumentace -- samotný vygenerovaný kód funguje jako dokumentace. Na základě něj víš, jak se ty atributy jmenují, jak jsou strukturované.

Pokud tohle neuděláš a pracuješ jen s nějakými hashmapami nebo dynamickými objekty, tak máš jen hromadu hnoje, která možná pasuje na to rozhraní a možná taky ne -- což se pozná, až když se to spustí. A možná se to bude jen chovat divně/chybně, protože čteš z té mapy podle klíčů, které tam nejsou a nikdy být nemohou, nebo zapisuješ na místa, která si na druhé straně nikdo nepřečte. Ta struktura požadavků/odpovědí není nikde na jednom místě vyjádřená -- je rozesetá po celém kódu a nekompletní.

Z meho pohledu je to vyhoda, protoze se ti v kodu neobjevuji chuchvalce vygenerovaneho kodu a mas uplnou kontrolu nad tim, co se jak deje a proc.

Kontrolu nad tím právě nemáš, viz výše. Chuchvalce to nejsou. Ten kód se standardně generuje v rámci kompilace a není uložený ve verzovacím systému (tam máš jen to WSDL/XSD). A výsledkem generování (v případě Javy) jsou jednoduché POJO třídy resp. DTO s gettery/settery a anotace (tam bývají jmenné prostory). Naopak když jsem koukal na to, co leze z toho Swagger generátoru, to jsou daleko větší hnoje. V podstatě jediný způsob, jak to používat, je napsat si vlastní šablony (není to až tak moc práce, ale stejně...).

Presto v rade situaci radsi sahnes po regularnich vyrazech, protoze jsou proste jednodussi na pouziti.

Regulární výrazy jsou skvělé, hlavně v tom, že je to pár znaků a už těchto pár znaků přináší nějakou hodnotu (najde vzor v textu, vyhodnotí shodu textu se vzorem, vytahá z textu skupiny znaků). Je to jednodušší než popisovat gramatiku nějakým sofistikovanějším způsobem, stavět AST a zpracovávat události nebo s tím stromem nějak pracovat. Na spoustu věcí se to hodí, hlavně na ruční práci s textem, hledání, základní nahrazování a pak na validaci jednoduchých formátů. Ale jakmile narazíš na limity regulárních výrazů, tak končíš a musíš už použít něco jiného.

Podobne je to s REST a WS.

Pokud budu chtít v cronu každou hodinu zkontrolovat stav něčeho a na základě toho zavolat či nezavolat nějaký příkaz, tak v tom RESTu to může být GET požadavek, který nevrací JSON, ale jen atomickou hodnotu nebo ani to ne a vrací jen HTTP stavový kód. U takhle triviálních případů to může být jednodušší. Ale dál už je to srovnatelné (viz začátek tohoto komentáře) a pokud bych neměl kontrolovat jen triviální atomickou hodnotu, ale měl bych propojit dva systémy (často desítky nebo stovky služeb, strukturované požadavky a odpovědi), tak by se mi asi i dnes dělalo líp s tím SOAPem. Je sice pravda, že Swagger/OpenAPI ten náskok WSDL pomalu dohnal a dneska už to generování kódu začíná být použitelné, ale že by to bylo nějak výrazně lepší, to mi nepřijde. Je to jen jiný nástroj, který dělá v principu to samé. Vznikl později, takže z některých chyb se poučil, ale nové zase nasekal. Komplexita dost narostla, takže ani z tohoto pohledu to není nějaká výhra nebo aspoň zlepšení.

[deda.jabko]

Poslepovat tu zprávu je trochu opruz v obou případech -- jak XML, tak JSON bys měl escapovat.

Složitost při ručním provolávání na základě specifikace mi přijde stejná. Pokud máš místo specifikace příklady, tak je jen upravíš a provoláš, takže je to zase stejné.

V pripade SOAP je to IMHO nasobne komplikovanejsi a osobne neznam nikoho, kdo by to byl schopen z hlavy dat jen podle pohledu na specifikaci volani, mozna se najdou vyjimky, ale ty ted nejsou na tolik podstatne. V pripade RESTu je to schopna udelat drtiva vetsina programatoru.

Není. Klidně můžeš XML požadavku postavit dynamicky nějakou knihovnou nebo poslepovat z kusů textu. Odpověď pak můžeš zpracovat třeba XPath dotazy nebo SaX parserem. Nikdo tě nenutí si ty třídy generovat.

Ano, muzu, ale to API/protokol mi v tom prilis nepomaha.

Ten kód se standardně generuje v rámci kompilace a není uložený ve verzovacím systému (tam máš jen to WSDL/XSD).

A to je to, co se mi nelibi. Mas tam kod, ktery jsi ty nevytvoril, a musis verit, ze proste funguje.

A výsledkem generování (v případě Javy) jsou jednoduché POJO třídy resp. DTO s gettery/settery a anotace (tam bývají jmenné prostory)

Pokud tohle neuděláš a pracuješ jen s nějakými hashmapami nebo dynamickými objekty, tak máš jen hromadu hnoje, která možná pasuje na to rozhraní a možná taky ne

POJO je stejny problem jako ty tebou vysmivane hashmapy, ale spouste lidi to prijde vic objektove a tak si mysli, ze je to v pohode. Problem tkvi v tom, ze pokud posles objekt jenom tak pres WS, zacne ti prosakovat vnitrni implementace jednoho modulu do modulu dalsich. V opacnem smeru, pokud budes pouzivat vygenerovane "objekty", zacne se ti vytvaret zavislost na jinem modulu.

Pokud tedy chces mit dobre udelane API a pouzivat API rozumne, musis mit na rozhrani vrstvu, ktera ti bude transformovat predavane hodnoty, aby odpovidaly objektum pouzitym v danem modulu. Jinak prijdes o rozumnou modularitu. A ten kod pro transformaci objektu stejne musis udelat +/- rucne a pak je jedno, jestli zpracovavas nejaky objekt nebo hashmapu. Uznavam, typova kontrola tu muze byt vyhodou, ale ten rozdil neni nejak markantni (z vlastni zkusenosti).

Naopak když jsem koukal na to, co leze z toho Swagger generátoru, to jsou daleko větší hnoje. V podstatě jediný způsob, jak to používat, je napsat si vlastní šablony (není to až tak moc práce, ale stejně...).

Tak ten Swagger nepouzivej. S REST API pracuji old-fashioned style a zase tolik prace to neni.

Regulární výrazy jsou skvělé,

To ja vim, neni potreba to opakovat. Podstatou sdeleni bylo, ze REST na spoustu veci je naprosto dostacujici stejne jako ty regularni vyrazy, a pokud potrebujes neco slozitejsiho pouzijes slozitejsi nastroj.

Je smutné, jaké dogma se z toho stalo, a že dneska "musí REST dělat každý", aby nevypadal "zpátečnicky" -- i když tento model/styl na jeho úkol nepasuje, je nepřirozený a daleko víc by se hodilo RPC. Spousta lidí/týmů se tak vrátila někam do počítačového pravěku, připravila se o šikovné nástroje a tvářila se přitom, jaký dělají pokrok...

Kdyz jsem se o webove sluzby zacal zajimat nekdy chvilku po roce 2000, vsichni to videli jako velkou vec, ktera umozni spojovat jednotlive aplikace a vytvaret pomoci internetu velke nepredstavitelne veci. Nakonec se to maximalne v korporatech pro integraci podnikovych systemu, kde si teda myslim, ze to bylo vetsinou rozhodnutim shora.

Samotny boom spontanniho propojovani a vytvareni novych sluzeb na zaklade verejne dostupnych rozhrani ale nastal az s adopci RESTful API a ta motivace je podle me primarne diky rozhodnutim zdola, protoze se REST drzi principu KISS, ktery znacne snizuje vstupni barieru pro pouziti takoveho rozhrani.

[xkucf03]

V pripade SOAP je to IMHO nasobne komplikovanejsi a osobne neznam nikoho, kdo by to byl schopen z hlavy dat jen podle pohledu na specifikaci volani, mozna se najdou vyjimky, ale ty ted nejsou na tolik podstatne.

Nemyslím, že bych byl až tak výjimečný :-) Schválně jsem si zkusil provolat jednu SOAP službu jen na základě WSDL a XSD. Anonymizovaná verze:

echo '<someRequest xmlns="http://xmlns.example.com/service123/">...</someRequest>' | curl -v -X POST -H "Content-Type: application/xml" -d @- http://jmeno:heslo@localhost:8080/.../api

1) Musíš znát URL, protože v tomto případě ho ve WSDL nemáme (služba může běžet na mnoha různých místech, nedáváme tam jedno výchozí). To jsem si tedy našel jinde.

2) Musíš zadat Content-Type, jinak se s tebou služba nebaví (vrátí chybu).

3) Musíš znát strukturu požadavku -- tu jsem si přečetl v XSD. Navíc tu máš výhodu, že když už trefíš ten kořenový element, tak ti služba napovídá (pokud nejsou vypnuté chybové hlášky) a řekne ti, jaké pod-elementy očekává.

Podle mého triviální. Tohle by měl dát i šikovnější středoškolák.

Schválně řekni, který z těch bodů se netýká RESTu/JSONu. IMHO se ho týkají všechny -- pokud ti něco z toho chybí, tak si neprovoláš ani SOAP, ani REST.

V pripade RESTu je to schopna udelat drtiva vetsina programatoru.

Jako že si přečte specifikaci ve Swaggeru a bude schopný službu provolat? Asi ano, ale nepřijde mi to nějak jednodušší. Jednou je to v XML, jednou je to v YAMLu, ale princip je úplně stejný. Definice služeb + definice datových typů/struktur. Někomu přijde čitelnější¹ YAML, někomu XML, to už je spíš otázka vkusu.

Opravdu jsou ty změny tak zásadní, aby bylo kvůli nim nutné projít celým IT cyklem (zavádění nové technologie) a přetrpět ty dlouhé roky, kdy chyběly základní nástroje a vše se dělalo ručně? Ručně se psala dokumentace a na druhé straně se z ní ručně zase opisovalo do kódu (a mnohde to tak dělají dodnes). Podle mého ne. Celý obor na tom promrhal spousty času, kdy se neřešila byznys logika, ale jen to, jak technicky propojit dva systémy, a to, zda někdo při opisování názvu atributu neudělal chybu. A výsledek? Jsme v podstatě zase tam, kde jsme byli.

Ano, technologie se obměňují, je to přirozené a v zásadě dobré. Jinak bychom dodnes propojovali systémy technologií CORBA/IDL (předchozí iterace téhož principu). Ale je otázka, zda novou technologii ve velkém nasazovat už v době, kdy je nezralá a výrazně horší než ta původní. Myslím si, že ne. Bohužel ani IT se nevyhýbají módní trendy a povrchní davové chování.

Tak ten Swagger nepouzivej. S REST API pracuji old-fashioned style a zase tolik prace to neni.

Je i není. Pokud je služba složitá a rozhraní se nemění, tak ta režie ručního napsání DTO tříd je celkem zanedbatelná. Pokud ale děláš hodně jednoduchých služeb nebo se ti rozhraní mění v průběhu vývoje, tak to problém je. Ale jde o ten princip -- vždy je to práce zbytečná -- protože to nemusel dělat člověk -- mohl to za něj udělat počítač díky strojově čitelné definici rozhraní.

JS1 tu píše o svých vizích, jak by se ve strojově čitelné formě psala i analýza/zadání. Já tomu fandím a třeba se k tomu jednou dopracujeme. Ale přijde mi smutné, že dneska nejsou lidi často schopní ani použít nástroj, pro strojově čitelnou definici rozhraní toho navrhovaného systému. Už to by ušetřilo spoustu práce a je to takový první krok správným směrem. Přijde mi vyloženě hloupé tenhle krok nedělat resp. dělat dokonce krok zpátky (přecházet z technologie, která to strojově čitelné rozhraní má, na technologii, která ho -- toho času -- nemá).

Podstatou sdeleni bylo, ze REST na spoustu veci je naprosto dostacujici stejne jako ty regularni vyrazy, a pokud potrebujes neco slozitejsiho pouzijes slozitejsi nastroj.

Jenže regulární výrazy mají ty limity poměrně vysoko a taky je normální, že když na ně člověk narazí, tak si řekne: aha, teď už musím použít plnohodnotný programovací jazyk, nebo si tu gramatiku popsat v něčem mocnějším. Nikdo se mu nebude posmívat, že přechází z regulárních výrazů jinam. Jenže z RESTu se stalo víceméně dogma² a ten, kdo ho nepoužívá, pomalu aby chodil kanálem. Časem, asi už brzy, se něco podobného stane s GraphQL³ pokud se toho chytnou dogmatici a začnou to cpát všude a rozjíždět FUD proti těm, kdo používají jiné technologie.

a pokud potrebujes neco slozitejsiho pouzijes slozitejsi nastroj.

Tohle je právě u RESTu problém. Málokdo si řekne, že to chce změnu, ve chvíli, kdy píše už desátou službu ručně a přijde mu to nešikovné a hodilo by se mu rozhraní generované ze strojově čitelné specifikace. Dneska může v tu chvíli aspoň začít používat ten Swagger, sice to dře, ale jakž takž to účel splní. Dlouhé roky ale nic takového neexistovalo a ruční opisování bylo jedinou volbou. Lidi byli zblblí z toho, že zavolání triviální služby (resp. opsání příkladu) je jednoduché a vybrali si to jako technologii pro propojení systémů (mnoho služeb). Jenže to, co vypadá dobře na HelloWorld příkladu, ještě nemusí být dobře použitelné v praxi. Jenže pak už jen tak nepřejdeš z RESTu na SOAP, protože jednak nechceš předělávat už hotové služby, a jednak tu jela ta propaganda, že REST/JSON je novější a lepší, zatímco SOAP/XML je pro zpátečníky.

Nakonec se to maximalne v korporatech pro integraci podnikovych systemu

Ono se to sice jmenuje Webové Služby, ale s webem to zase tak moc společného nemá. Jen ten podkladový protokol (HTTP) a ani ten tam není nutný, protože ty SOAP zprávy si můžeš posílat klidně e-mailem nebo nějakým jiným kanálem. Takže ano, přijde mi to jako dobrá volba primárně pro podnikové systémy a nějaké větší aplikace. Vůbec to nemusí mít nic společného s webem.

Samotny boom spontanniho propojovani a vytvareni novych sluzeb na zaklade verejne dostupnych rozhrani ale nastal az s adopci RESTful API

A nebo to vůbec nebylo podmíněné technologií a šlo spíš o posun ve společnosti a v myšlení lidí, který shodou okolností probíhal ve stejnou dobu (a dost možná mu SOAP vyšlapal cestu). Šlo o změnu myšlení v tom smyslu, že když mám nějaký server a na něm data/služby, tak nemusím mít monopol na to UI a můžu se o tyto hodnoty podělit i s někým dalším a poskytnout mu API, aby ty moje služby volal nebo přistupoval k mým datům. Tzn. nedívat se na to tak, že někdo jiný vykrádá moje data, ale tak, že jde o oboustranně výhodnou spolupráci, která může vést k synergickému efektu (buď se za to bude platit přímo, nebo mi to třeba přitáhne nové uživatele, někdo použije moji službu/data jiným způsobem, který mě nenapadl, proslaví moji službu, přinese zisky někde jinde atd.).

Nechci to pořád opakovat, ale v zásadě jde jen o jiný tvar závorek a data se pořád předávají přes HTTP. Kdybys ve správnou dobu poskytl lidem dostatek služeb a praktických příkladů, jak volat SOAP, tak by dneska všichni psali ostré závorky místo složených.

_{[1] mimochodem, číst YAML bez editoru s jeho podporou (ideálně toho Swagger Editoru) je docela problém, protože si musíš hlídat úroveň odsazení, zatímco u toho XML jsi aspoň schopný skočit na koncovou značku (a tím pádem konec daného bloku) pomocí vyhledávání textu (což umí prakticky každý editor, i less)
[2] pod vlivem propagandy RESTu/JSONu a nenávistné kampaně proti WSDL a obecně XML technologiím; dlouho např. lidi od RESTu říkali, že strojově čitelný popis rozhraní nepotřebují -- a říkali to ve skutečnosti proto, že v té době nic takového neměli a jejich technologie byla nezralá -- a postupem času vyrobili ten Swagger a znovu-vynalezli kolo
[3] což je mimochodem celkem hezká myšlenka a mohla by se dobře doplňovat se SQL; líbila by se mi nativní podpora třeba v PostgreSQL; ale taky z toho může být jen bloatware a další vrstva abstrakce, která jen zvyšuje komplexitu systému}

[xkucf03]

Anonymizovaná verze:

Vypadlo mi z toho Envelope/Body.

[deda.jabko]

Musíš znát strukturu požadavku -- tu jsem si přečetl v XSD.

Pres toto se vetsina lidi neprehoupne. Ano, muze to zvladnout stredoskolak, ale pro vetsinu lidi je to konecna. Bez podpory nastroju se nehnou.

Srovnej napriklad. Vidis format zprav, muzes okamzite pouzivat.

Jako že si přečte specifikaci ve Swaggeru a bude schopný službu provolat?

Proc jsi porad fixovany na ten Swagger? Bez toho jako nejde udelat dokumentace k API? Bez toho nejde pouzivat?

Ale je otázka, zda novou technologii ve velkém nasazovat už v době, kdy je nezralá a výrazně horší než ta původní.

Ale ta technologie je nezrala jenom z tveho uhlu pohledu. Ta technologie je perfektne pouzitelna a dokazuje to tim, ze dokazala naplnit vizi te (dle tebe) dokonalejsi technologie.

JS1 tu píše o svých vizích, jak by se ve strojově čitelné formě psala i analýza/zadání. ... Už to by ušetřilo spoustu práce a je to takový první krok správným směrem. Přijde mi vyloženě hloupé tenhle krok nedělat resp. dělat dokonce krok zpátky (přecházet z technologie, která to strojově čitelné rozhraní má, na technologii, která ho -- toho času -- nemá).

To je ale diskuze mezi staticky a dynamicky typovanymi jazyky jen prevlecena do jineho kabatu. Jsou scenare, kde je vyhodnejsi dynamicke typovani a kdy staticke. Jsem dalek toho rikat, ze jeden smer je horsi a druhy lepsi.

Je i není. Pokud je služba složitá a rozhraní se nemění, tak ta režie ručního napsání DTO tříd je celkem zanedbatelná.

Psani, resp. pouzivani, DTO se snazim maximalne vyhnout a radsi pouzivam plnohodnotne objekty, ktere maji metody a tak. Jednou dostanu data na rozhrani, tak z toho udelam poradny objekt.

Jenže regulární výrazy mají ty limity poměrně vysoko a taky je normální,

Ty limity jsou proklate nizko. Staci cokoliv, co se do sebe muze libovolne zanorovat. Lide zkousejici parsovat HTML nebo XML pomoci regularnich vyrazu opravdu nejsou nic neobvykleho. A i presto, ze se najdou takovi lide, nedovolil bych si oznacit regularni vyrazy za nezralou technologii.

Šlo o změnu myšlení v tom smyslu, že když mám nějaký server a na něm data/služby, tak nemusím mít monopol na to UI a můžu se o tyto hodnoty podělit i s někým dalším a poskytnout mu API, aby ty moje služby volal nebo přistupoval k mým datům. Tzn. nedívat se na to tak, že někdo jiný vykrádá moje data, ale tak, že jde o oboustranně výhodnou spolupráci, která může vést k synergickému efektu (buď se za to bude platit přímo, nebo mi to třeba přitáhne nové uživatele, někdo použije moji službu/data jiným způsobem, který mě nenapadl, proslaví moji službu, přinese zisky někde jinde atd.).

Ale s touto myslenkou puvodne prisly WS a nakonec se stejne pouzivaly na neco jineho. Mels k tomu treba UDDI, coz dneska supluje Apiary a spol. Ale lidi to proste nechteli, protoze je to zbytecne komplikovane a nasli si neco lepsiho.

Kdybys ve správnou dobu poskytl lidem dostatek služeb a praktických příkladů, jak volat SOAP, tak by dneska všichni psali ostré závorky místo složených.

Ty priklady tady byly v roce 2000, 2005, 2010, 2015, ... ale nikdo to nechtel pouzivat tak, jak to bylo zamysleno a misto toho si vzali REST.

Jenže pak už jen tak nepřejdeš z RESTu na SOAP, protože jednak nechceš předělávat už hotové služby, a jednak tu jela ta propaganda, že REST/JSON je novější a lepší, zatímco SOAP/XML je pro zpátečníky.

Jak neprejdes? REST nevylucuje pouziti SOAP, systemy poskytujici obe rozhrani jsem uz videl. A sam jsi prece tvrdil, ze to jsou jedna o jiny tvar zavorek, ne?

Ja nevim, o jake propagande porad mluvis. Znam obe technologie, pouzival jsem oboji. A kdybych si mel vybrat, tak volim REST, protoze je jednodussi, obejdu se bez generatoru kodu, znalosti slozitych standardu a pouziti v libovolnem jazyce je primocare ve vetsine beznych jazyku, bez ohledu na to, jestli se jedna o Javu, Python, Bash nebo C.

[Bystroushaak]

Kdyz jsem se o webove sluzby zacal zajimat nekdy chvilku po roce 2000, vsichni to videli jako velkou vec, ktera umozni spojovat jednotlive aplikace a vytvaret pomoci internetu velke nepredstavitelne veci. Nakonec se to maximalne v korporatech pro integraci podnikovych systemu, kde si teda myslim, ze to bylo vetsinou rozhodnutim shora.

Samotny boom spontanniho propojovani a vytvareni novych sluzeb na zaklade verejne dostupnych rozhrani ale nastal az s adopci RESTful API a ta motivace je podle me primarne diky rozhodnutim zdola, protoze se REST drzi principu KISS, ktery znacne snizuje vstupni barieru pro pouziti takoveho rozhrani.

+1

[JS1]

Jinak jeste k tomu:

Co si myslíš třeba o takovém Swagger Editoru (OpenAPI)? Je schůdné, aby tenhle nástroj používal byznysový analytik a definoval v tom rozhraní mezi systémy?

Snad radsi ne.. Vetsina lidi ma IMHO zcela chybnou predstavu, co je API. To co se definuje treba v Java Interface, totiz nazvy metod a parametry, je ta mene podstatna cast. Ta podstatna cast (tohle mam od Erika Meijera, mimochodem) jsou zakony (vztahy), ktere plati mezi jednotlivymi volanimi toho API. Napriklad, pokud zavolam tuhle metodu a pak tuhle metodu tak mi tamta metoda vrati totez apod.

Zase, tohle je pomerne funkcionalni (matematicky) pohled. Ale ja s nim souhlasim.

[xkucf03]

Mám na to stejný pohled a jsem rád, že to píšeš. Vždycky se podivuji nad tím, když se o někom mluví jako o tom, kdo "dělá to API" a pak se ukáže, že ten člověk nenavrhuje API (ten logický pohled), ale pouze obsluhuje nástroj, který generuje nějaké třídy/definice nebo vystavuje API v nějakém katalogu a nastavuje práva na jednotlivé služby. Odborník na API by podle mého měl být v první řadě analytik, který navrhuje datové struktury (zprávy předávané tím API) a jednotlivá volání a jejich logiku; dokáže si představit i jiné formy interakce, než jen požadavek-odpověď, a umí je na vhodných místech použít.

Další věc, která mne zaráží je, že spousta lidí zaměňuje API a REST API -- jako by žádné jiné neexistovalo. Přitom API je rozhraní mezi systémy/komponentami a to může být realizované mnoha různými způsoby a technologiemi. API jsou rozhraní knihovních metod/funkcí nebo systémová volání nebo formát zpráv a systém front přes které se tyto zprávy posílají, API může být klidně i adresář a určitý formát souborů, které se do něj dávají atd.

Když se vrátím k tomu Swaggeru. Šlo mi o to, zda analytik, který dojde k tomu, že ideální forma interakce je požadavek-odpověď a že se použije HTTP, a navrhne na logické úrovni to rozhraní (jaká volání tam budou, jak se budou používat, jaké struktury/atributy se tam budou předávat), tak jestli je pak schopný (nebo měl by být) vyjádřit tuhle myšlenku pomocí textového zápisu YAMLu ve Swagger Editoru. Protože pokud by nebyl schopný ani toho, tak jak by pak měl používat nějaké DSL k popisu vnitřního chování systému/komponenty? (když není schopný ani ve strojově čitelné podobě popsat rozhraní tohoto systému/komponenty) Nebo je to nevhodný nástroj/implementace? (možná ano).

Nebo by to měli dělat jiní lidé než současní analytici? Měli by to být spíš programátoři, kteří se posunou blíž tomu byznysu? A co by dělali současní analytici?

[Bystroushaak]

...přestože tohle vzniklo v oboru telekomunikací a mělo to původně směrovat SMSky, časem se přišlo na to, že s tím můžeš směrovat i zprávy o účtování těch SMSek (používá se jen jiný protokol, ale princip je stejný), dá se na tom postavit klidně chat (IM server), umí to fungovat jako HTTP nebo SMTP klient (server by v tom šlo napsat taky, kdyby někdo zadal vývoj příslušného modulu)... klidně bys na tom mohl postavit hru, řídit tím továrnu nebo to použít jako celkem klasický aplikační server. A ten jazyk byl obecný programovací jazyk, ve kterém se jinde psaly klidně i desktopové aplikace.

Co to je za jazyk?

[xkucf03]

Nic převratného. Jádro a moduly/konektory v C++ a skriptování nad tím v Pascalu. Nebyly tam ani funkce, jen procedury, takže to bylo trochu nepohodlné, ale psaly se v tom poměrně jednoduché věci, takže to až tolik nevadilo. Nemyslím si, že by Pascal byl nějak extra vhodný, spíš byl v době vzniku po ruce. Ale výsledný produkt byl dobrý. Práce spočívala v tom, že jsi udělal detailní analýzu, nakreslil si, co má s čím komunikovat, jak ten proces nebo tok dat má vypadat a pak sis to napsal v tom Pascalu a v konfigurákách. Člověk se tam soustředil víc na tu byznys logiku než že by si hrál s technologiemi (to ani nešlo, protože ten jazyk toho opravdu moc nenabízel).

To C++ chápu (často ten modul stavěl na nějaké knihovně pro daný protokol v C nebo C++), ale místo Pascalu bych volil něco jiného. A samozřejmě by to šlo celé napsat i v Javě a bylo by to taky dobré. Je to spíš o té architektuře než o programovacím jazyku.

[JS1]

Nechci mluvit za JS, ale predpokladam, ze mu asi vadi, ze v takovych systemech driv nebo pozdeji dojde k prolinani nizsich a vyssich urovni abstrakce, kdy vysokourovnovy kod, ktery by se mel venovat ciste dane domene a byt strucny a srozumitelny je zapleveleny spoustou low-level veci, jako je prace se seznamy, slovniky, apod. Ale to si myslim je resitelne dobre navrzenym API a vhodnymi restrikcemi at uz na urovni jazyka ci best-practices.

Myslim si, ze to chapes spravne. V cem se ale neshodneme je to, ze ja povazuji ten socialni problem (zhruba receno, zpusob, na jehoz zaklade vybirame programatora vhodneho pro projekt) za podstatny faktor, zatimco ty zda se tvrdis, ze to lze resit pomoci best-practice. A z toho se pak samozrejme i lisime v nazoru, jak by se ten problem mel resit.

[deda.jabko]

V cem se ale neshodneme je to, ze ja povazuji ten socialni problem (zhruba receno, zpusob, na jehoz zaklade vybirame programatora vhodneho pro projekt) za podstatny faktor, zatimco ty zda se tvrdis, ze to lze resit pomoci best-practice.

Ja s tebou souhlasim v tom, ze to je do jiste miry socialni (resp. organizacni) problem. Ale moc se mi nezda predstava, ze resenim je udelat pomoci DSL tlustou caru mezi frameworkem a implementaci aplikacni logiky.

K tomu, aby DSL (nebo obecne jazyk) byl dobre pouzitelny potrebuje tri veci -- dobrou koncepci, dokumentaci a tooling. Pokud jedno z toho bude zaostavat, bude takovy jazyk k vzteku a jeho pouziti bude jen kontraproduktivni. S koncepci u DSL je problem, ze casto vyvoj zamrzne nekde v minulosti a pote uz nikdo nema odvahu reflektovat nove znalosti a zkusenosti, ktere se za nekolik poslednich petiletek ziskaly, protoze se desi toho, kolik veci by se mohlo rozbit.

S nastroji okolo jazyka je taky problem, protoze dotahnout je na svem vlastnim DSL na uroven, jakou ma treba Java je potiz. Hezky to jde videt treba na Scale, ktera i presto, ze patri do main-streamu a stavi na Eclipse, tak nastroje pro Scalu jsou v te same verzi Eclipse o rad horsi nez pro Javu.

DSL sice bude mit tu vyhodu, ze nejaky problem popise rychleji efektivneji, ale prace s tim bude utrpeni, protoze na jeho vyvoj potrebujes nemale zdroje.

Druhy problem s DSL jako barierou mezi aplikacnim a systemovymi programatory vidim v ekonomicke rovine. Programator specializujici na konkretni domenu a hlavne konkretni DSL se hur hleda a hur nahrazuje, takze jejich cena neumerne roste.

zatimco ty zda se tvrdis, ze to lze resit pomoci best-practice

Je to spis takovy pragmaticky pohled, i kdyz vim, ze to reseni neni 100%. V minulosti taky bylo obvykle, ze kod v Pascalu/C byl prokladany assemblerem, pak si lidi odvykli. Podobne v C++ jsou mistri na to rikat, jak se co nesmi pouzivat, i kdyz je to porad validni kod C++.

Takovy praktictejsi pohled bych videl v tom, ze jedna cast lidi tvori API/EmbeddedDSL a rekne se, ze aplikacni programatori mohou pouzivat jen volani konkretnich modulu, cokoliv, co je mimo, je potreba zduvodnit (podobne jako v Pascalu/C inline assembler.) Pokud se nejaky pozadavek/vzor na prekroceni bariery opakuje vicekrat, pak je cas zaradit to do API/EDSL nejak koncepcne.

Mam treba takto udelany (EDSL) Prolog ve Scale, kdy se pomoci Prologu definuje konfigurace, a prakticky tam takove zadne prosakovani mezi vrstvami nevznika.

[xkucf03]

zhruba receno, zpusob, na jehoz zaklade vybirame programatora vhodneho pro projekt

Programoval jsem v bankovnictví, pak v telekomunikacích, teď opět v bankovnictví a příště to bude zase jiný obor. Přijde mi výhodnější se specializovat na technologie, než na obor. Resp. přejít z jednoho oboru do jiného není žádný problém. A když člověk ty technické znalosti/schopnosti má, tak mi přijde škoda se omezovat na jeden obor. To je osobní pohled jednotlivce.

A z pohledu firmy? Současná situace je taková, že programátorů je málo. Teoreticky by mohlo být cestou to, co navrhuješ, tedy vrhnout těch pár programátorů, kteří ti zbyly, na tvorbu projektu DSL pro tvůj obor, a předpokládaný výsledek by byl, že díky tomu DSL se do tvorby aplikací bude moci zapojit více (levnějších) lidí a v konečném součtu to bude ziskové. Opět se musím vrátit k tomu přirovnání k BPEL a obecně vizuálním nástrojům -- ten princip je totiž stejný (investuješ, připravíš si nástroj, a ten ti pak bude šetřit práci). Otázka je, proč to ta firma neudělá a radši pošle ty programátory vyvíjet nějakou aplikaci. Teoreticky tak ta firma sice uvázne v lokálním maximu -- ale na druhou stranu, kdyby vyvíjela DSL a nedělala zakázky, za které dostane v aktuálním roce zaplaceno, tak by zkrachovala.

Málokterá firma si to může dovolit (např. rok nebo spíš déle si vydržovat tým lidí, kteří nepřinášejí aktuálně žádný zisk). To může leda tak někdo jako IBM, ale ti si pak nechají výsledek pro sebe a od ostatních budou chtít tučně zaplatit. Pokud by mělo dojít k nějaké revoluci resp. posunu, který by se týkal všech a byl všem dostupný, muselo by to být na bázi svobodného softwaru. A tady je otázka, jak ten projekt vést a koordinovat decentralizovanou práci mnoha různých lidí na něčem tak abstraktním (a v prvních verzích neužitečném).

Nebo je možnost to řešit po malých krocích a to DSL vyvíjet v rámci aktuálního projektu pro zákazníka (ať už externího nebo interního). To je schůdnější a mnohdy se to tak i samovolně děje (programátor si připraví nějaký společný kód, který mu pak šetří práci -- mohlo by to být i to DSL nebo někdy i je). Ve větším měřítku do toho ale potřebuješ namočit i ty analytiky a přimět je, aby mysleli kompatibilně s DSL, aby jeho smysl chápali a jeho vznik podporovali. A tady je zase problém v tom, že se často dělají naprosto elementární učebnicové chyby (jak v analýze, tak v programování), natož aby ten tým byl schopný vymyslet nějaké DSL (ve větší míře -- nemyslím to, kdy DSL vzniká nějak živelně odspodu v malém) nebo obecně nějaké abstrakce a znovupoužitelný návrh. K tomu si připočti neblahé zkušenosti firem s vývojem tzv. do šuplíku (programátoři nebo obecně vývojáři si s dlouho s něčím hráli a pak to firmě k ničemu nebylo).

[JS1]

Nemam zadny duvod si myslet, ze zmenit pouzivanou technologii je jednodussi nez zmenit domenu, nebo naopak.

Proto mi dava smysl mit dva lidi. Jeden je SW inzenyr, co zna technologie (a nektere do hloubky), ale nemusi se zabyvat domenami. Druhy je analytik, ktery zna domeny (zase do hloubky), ale nemusi ho trapit pouzivana technologie.

A cim vic toho vime (at uz jde o domeny nebo technologie), tim snazsi je naucit se dalsi. Proto specializace na jedno nebo druhe dava smysl.

[xkucf03]

Nemam zadny duvod si myslet, ze zmenit pouzivanou technologii je jednodussi nez zmenit domenu, nebo naopak.

Nejde o to, co je jednodušší, ale co je výhodnější pro daného člověka. Obory se různě vyvíjejí, někdy rostou, jindy jsou v útlumu. Může s tím zamávat i stát skrze nějaké dotace -- najednou bude spousta práce v jednom oboru, pak se změní vláda nebo projekty skončí a najednou je spousta lidí bez práce. Obor může postihnout krize atd.

Oproti tomu ty technologie mi přijdou větší sázka na jistotu. Dodnes se oprašují prastaré technologie a než něco opravdu umře, tak to trvá hodně dlouho. Takže ten současný stav, kdy se používají spíše obecné jazyky, je pro programátory vlastně výhodný. I kdyby tvůj původní obor šel ke dnu nebo ses třeba přestěhoval, tak půjdeš dělat víceméně to samé akorát do jiného oboru.

Ale abys v tom nehledal nějaký zlý úmysl nebo spiknutí programátorů -- představ si, že jdeš zákazníkovi nabídnout, že mu naprogramuješ DSL a pomocí něj si jeho lidé (neprogramátoři) budou tvořit aplikace. Pokud nemáš úchvatně vypadající hotové řešení (a tady je víceméně nutný předpoklad, že to bude vizuální -- ne nějaký textový zápis kódu), ze kterého si manažeři sednou na zadek, tak tě s tím vyženou a řeknou ti, že jim máš vyvinout aplikaci a ne nějaké DSL.

[johnyK]

ted je jenom otazka, co se stane az prijde ten prumysl 4.0

Potom budou komunikovat stroje mezi sebou a ty aplikace nebudou vubec vypadat jakk dnes. Podle me se ztrati ta domenova specializace, protoze ty stroje si budou mezi sebou dohadovat co je treba dalsiho udelat a tyhleti agenti budou programovani temi softwarovymi inzenyry.

[deda.jabko]

ted je jenom otazka, co se stane az prijde ten prumysl 4.0

Ale abys v tom nehledal nějaký zlý úmysl nebo spiknutí programátorů -- představ si, že jdeš zákazníkovi nabídnout, že mu naprogramuješ DSL a pomocí něj si jeho lidé (neprogramátoři) budou tvořit aplikace. Pokud nemáš úchvatně vypadající hotové řešení (a tady je víceméně nutný předpoklad, že to bude vizuální -- ne nějaký textový zápis kódu), ze kterého si manažeři sednou na zadek, tak tě s tím vyženou a řeknou ti, že jim máš vyvinout aplikaci a ne nějaké DSL.

Ne, ze bych tomu extra rozumel, ale co jsem videl programovani prumyslovych robotu (Fanuc, Kukabot), tak se k nim dodaval krizenec mezi IDE a castecne vizualnim DSL. Takze tady se dostavame k tomu, co jednak chtel JS1 (roboty programuje nekdo s domenovou znalosti bez znalosti implementacnich detailu) a soucasne i xkucf (bylo to s obrazky).

[VSi]

Ano, průmyslové aplikace jsou celkem dobrým příkladem aplikace něčeho, co by se dalo nazvat DSL.

Roboty bývají ještě více "Specific" než generické PLC (Programmable Logic Controller) aplikace, kde se používají jazyky ve stylu normy IEC 61131-3 - jako DSL bych viděl zejména Sequential function charts (SFC) a ještě více grafický Function block diagram (FBD), možná i Ladder (LD). Dobrý příklad je také Simulink (block diagramy dovedené skoro k dokonalosti) a na něm postavené rozšíření jako např. SimMechanics, které umožňují lidem s doménovou znalostí abstrahovat od velmi složité matematiky a algoritmů pod tím. Kromě simulací to má velký význam i pro generování produkčního low-level kódu pro safety-critical systémy, kde ruční psaní v low-level jazycích nemá při dnešní složitosti funkcionality moc šanci na splnění regulatorních požadavků, nebo za cenu extrémní neefektivity.

Tyto aplikace často tvoří právě neprogramátoři, ale lidé s hlubokou znalostí control engineering domény, což je úplně jiná disciplína, a dobře to odpovídá tomu, o čem píše JS1.

[xvasek]

Průmysl 4.0 je jenom hromada nářadí a možností. Pořád musí přijít někdo, kdo řekne: "budeme tyto nástroje používat k těmto účelům a tady je přidaná hodnota" a pak se to musí implementovat. Naučit se nějaké best practices k tomuto je disciplína s programováním až tak moc nesouvisející a potom už je analytik ve světě, který dobře zná a který se od toho dnešního zase až tak neliší. Tady jenom přibývá něco, co se dá na nižší úrovní naučit, ale nic z toho, co tady bylo předtím, nezmizí.

[kralyk z abclinuxu]

Podle mého názoru a pocitu, aby to šlo taky prodat, je to celé o tom, že na správné vrstvě musí být správný jazyk. (...) Jakmile by přišlo na psaní uživatelské logiky, kterému musí rozumnět kozultant, programátor implementátora a programátor zákazníka, tak veškeré silně typované funkcionální jazyky musí stranou a musí přijít něco primitivního imperativního

Však jo, já vůbec neřešil tu aplikační / uživatelskou logiku. Mně přijde to rozvrstvení SQL + nad tím ORM/apod. jako principielně dobré, takže tu hypotetickou náhradu SQL bych viděl ve stejné roli, případně by mohla být pro ORM/frameworky snazší na navázání, ale dohromady bych to neslučoval.

[xkucf03]

Já mám rád SQL, nevadí mi ORM a ten klasický třívrstvý model mi celkem vyhovuje. Dá se s tím efektivně pracovat.

Ale na druhou stranu: stejně trávíme hrozně moc času řešením nějaké persistence a kopírováním dat mezi aplikačním serverem a databází. Resp. ve skutečnosti je třeba synchronizovat tři místa: 1) okolní hmotný svět 2) data načtená v paměti programu 3) data uložená v databázi nebo v souborech.

S tím okolním světem se bude potřeba synchronizovat vždy, ale proč by měl být nějaký předěl mezi daty načtenými v paměti a uloženými na disku? Proč by to nemohlo být něco jako namapovaný soubor do paměti, ovšem ne na úrovni bajtů ale objektů? K synchronizaci na disk by stále docházelo, ale mohlo by to být zcela transparentní (a asi spojené s transakcemi). Proč ale rozlišovat mezi daty načtenými ve formě objektů a neCOMMITnutými záznamy v databázi? Proč rozlišovat, jestli jsou data v mezipaměti aplikačního serveru, databáze nebo operačního/souborového systému? Není to jedno, když je to pořád ta samá a stejně rychlá RAM?

Poměrně dost se tomu blíží ORM a potom systémy, které mají aplikační logiku v uložených procedurách v databázi (tam jsou sice taky nějaké proměnné a data načtená v aplikační paměti, ale přece jen to má k uloženým datům poměrně blízko).

A pak jsou tu ještě extrémisté, kteří to celé zabalí do jednoho obrazu i s aplikační logikou. :-) (to mi ale moc dobré nepřijde, protože program a data mám raději odděleně a verzuji je nezávisle)

[johnyK]

...jakmile by přišlo na psaní uživatelské logiky, kterému musí rozumnět kozultant, programátor implementátora a programátor zákazníka, tak veškeré silně typované funkcionální jazyky musí stranou a musí přijít něco primitivního imperativního, co se podobá pascalu nebo basicu.

boze, my se porad tocime kolem dokola.

Patrne zcela intuitivne ale presto spravne volas z praktickych duvodu po tom, aby ten programator u zakaznika mohl pouzivat neco primitivniho, imperativniho. To uz vlastne stoji v tom tvem uplne prvnim prispevku nahore. Spravne z toho duvodu, ze my lide musime vynalozit urcite mentalni usili, jestlize chceme nase prani, myslenky, cile vyjadrit 'deklarativne. (i kdyz pan Stehule neunavne tvrdi opak - dokladem, ze se myli jsou kazdodenne ty tisice SQL kurzu na celem svete a to uz pres 30 let)

A v tech tvych prikladech je to take nazorne videt jak to muze vypadat. JS1 take z tebe bude mit radost, protze ty jsi si osvojil nejakou DSL a pouzivas ji a jses tim znacne produktivini. JS1 jeste tvrdi, ze takovych jako ty je malo a to z toho duvodu , ze se presne nevi kdo je inzenyr a kdo analytik a take neni ta komora tech inzenyru, ktera by vydavala ty certifikaty. A proto neexistuje mnohem vice domenovych jazyku, ve kterych by se psala ta business logika. Kdyby tady byly, tak by jiste existovaly a i mnohe, ktere by se daly nasadit i s relacnuimi databazemi a kazdy by si nejaky takovy domenovy jazyk vybral a ta nase diskuze by tu vubec nebyla.

Ja toto JS1 zduvodneni nesdilim. Ten duvod , proc to u tech relacnich nejde lezi na tom jiz jmenovanem impedance mismatch. Na rootu v te diskuzi o tech databazivh linkoval jeden diskutujici obsahly clanek, kde je to vysvetlene.

http://blogs.tedneward.com/post/the-vietnam-of-computer-science/

To ze to v pripade ABAS jde, (tedy alespon zcasti) je dano tim, ze nepouzivaji ciste rel. databazi ale tzv. log-databazi. Zrovna tak, by nebyl zadny problem u tech tech hierarchickych a nebo sitovych databazi. I tam by mohl ten aplikacni programator pouzit imperativni jazyk. Vezmeme ten tvuj priklad:

.select (od-faktury| do faktury)
LOOP
... tady se neco dela s kazdou fakturou, event. se na ni udela update
END LOOP

Tohle u tech hierarchickych a sitovych funguje. U relacnich nastane problem, nebot rel. databaze umi jen to jedno - jako vysledek dodaji nejakou vysledkovou mnozinu - tabulku. A podle toho, jak daleko od sebe jsou ty od-do faktury, tak podle toho to bude trvat, protoze ta vysledkova mnozina bude obrovska. Nerelacni databaze zadne vysledkove mnoziny nevytvareji a proto je u nich mozno postupovat primitivne, imperativne krok za krokem.

Kdyz tedy budeme chtit pristupovat k rel. databazi imperativne, tak ji bud musime zakazat vytvaret ty vysledkove mnoziny (to skutecne v jednom pripade existuje, a v pripade SQLite to v urcitych situacich tak take je) a nebo musi databaze nabidnout imperativni API (ten klasicky Cursor-machanismus - coz take ojedinele existuje, jak jsem jiz drive psal).

[JS1]

Nevim, proc bych mel mit z xvaska radost, kdyz s nim zasadne nesouhlasim.

Ja v tom ale nevidim problem, proc by jsi nemohl te databazi poslat funkci, ktera se ma provest nad tou vysledkovou mnozinou?

Takhle nejak funguje ten Haxl (viz casti tady nebo tady) - je to funkcionalni jazyk k zapisu filtrovani spamu atd. Tam se neresi, odkud se vzala ta mnozina, jen se s ni proste provedou nejake operace.. Proc to funguje? Protoze ta funkce vraci nejakou monadu, jejiz interpretace muze byt ruzna. To je hlavni rozdil a vyhoda oproti imperativnimu pristupu. V imperativnim pristupu rikame presne, co se ma vykonat. Ve funkcionalnim pristupu davame recept.. Jeho interpretace pak zalezi na tom, jak jsou technicky ta data ulozena (o to se ma prave starat ten inzenyr, a ne ten, kdo napsal ten recept).

Jinak ten clanek jsem linkoval ja.

[xvasek]

Prosím tě, co děláš v práci v normálním životě? (To není trolling, fakt mě to zajímá.)

Mně je to po technické stránce jasné, ale absolutně si nedovedu představit, že někam někdo přijde, naprogramuje tam nějaké funkcionální funkce a vystaví za to fakturu a někdo jiný si to převezme a tu fakturu proplatí. Nebo aspoň v takových těch "normálních" institucích, jako továrny, banky, velkoobchod, maloobchod...

To musí být nějaký zajímavý obor, jako vytěžování dat ze sociálních sítí, hledání léku na rakovinu nebo optimalizace provozu v deep space network nebo tak něco...

[JS1]

V normalnim zivote nic zajimaveho. Ale funkcionalni programovani je jeden z mych konicku.

Co me ale bavi ted nejvic je P=NP.

[xvasek]

Funkcionální jazyky už asi myšlenkově nerozchodím, ale teď jsem nedávno zkoušel Prolog. Byl to porod, ale ještě to šlo. U Prologu si monetizaci představit ještě dokážu, u funkcionálních jazyků jenom v dostatečně vědeckých oborech, ale je to pěkné paradigma.

Co se týká P a NP - teď jsem vedl u zákazníka diskusi, že jeho problém je NP-úplný, i když vypadá stupidně (naskládat z dostupných balení na skaldě přesně dané cílové množství) a tudíž na řešení, které poběží "vždycky rychle", bude muset ještě možná pár desetiletí počkat. Tak až to louskneš, dej vědět, já mu to pak předělám, nebo taky ne, podle toho, jak dopadneš.

[deda.jabko]

Funkcionální jazyky už asi myšlenkově nerozchodím, ale teď jsem nedávno zkoušel Prolog. Byl to porod, ale ještě to šlo. U Prologu si monetizaci představit ještě dokážu, u funkcionálních jazyků jenom v dostatečně vědeckých oborech, ale je to pěkné paradigma.

To je ponekud sverazna predstava a myslim, ze v tomto smeru (hlavne) Haskellisti delaji funkcionalnimu programovani medvedi sluzbu.

Prejit na funkcionalni programovani neni nic tezkeho a jde to udelat temer v jakemkoliv programovacim jazyce. V podstate si staci uvedomit nasledujici: Vsechny hodnoty (struktury, objekty) jsou nemenne, procedura (funkce) transformuje vstupni (nemenne) hodnoty na jine (nemenne) hodnoty a dalsi koncepty ti z toho prirozene vyplynou. Vysledna monetizace pak spociva v tom, ze ziskas kod, ktery je mnohem srozumitelnejsi, testovatelnejsi a zmizne ti cela rada nehezkych prekvapeni zpusobenych zmenami stavu. Tento postup lze uplatnit temer kdekoliv, bez ohledu na danou domenu.

[xkucf03]

Vysledna monetizace pak spociva v tom, ze ziskas kod, ktery je mnohem srozumitelnejsi, testovatelnejsi a zmizne ti cela rada nehezkych prekvapeni zpusobenych zmenami stavu.

Proč se z toho tedy dosud nestalo dominantní paradigma? A většinou¹ se programuje tak nějak objektově/procedurálně s funkcionálními prvky. Má funkcionální programování i nějaké nevýhody?

_{[1] uznávám, že tohle závisí i na prostředí/projektech, kde se člověk pohybuje -- někde to funkcionálno bude převládat, ale globálně nebo na běžných projektech podle mého nikoli}

[deda.jabko]

A většinou1 se programuje tak nějak objektově/procedurálně s funkcionálními prvky.

Mozna protoze jsou lidi ve sve podstate pragmatici.

Proč se z toho tedy dosud nestalo dominantní paradigma?

Kdyz jsem poprve videl funkcionalni programovani, tj. 15+ let zpatky, svetu (main streamu) kralovaly projekty v C/C++, Delphi, Visual Basicu a Java zacinala nabirat obratky. FP tehdy vypadalo jako koncept z jineho sveta a lambda vyraz neco neuveritelne akademickeho bez praktickeho pouziti.

Dnes, o patnact let pozdeji, FP v nejake mire podporuje vetsina mainstreamovych jazyku, nove vznikajici casto protezuji immutabilitu. Na principu, ze mas nejakou proceduru, ktera transformuje jednu hodnotu na druhou, jsou postaveny microservices. Nastroje pro analyzu dat map/reduce, Spark opet vychazi z FP. Daly by se najit asi i dalsi priklady.

Ono se to moc nezda, ale to FP opravdu prosakuje do mainstreamu cim dal vic. Nemalou zasluhu na tom (bohuzel) ma i JavaScript. Bohuzel proto, ze mi prijde, ze komunity kolem tohoto jazyka FP objevuji tak nejak metodou pokus omyl.

Má funkcionální programování i nějaké nevýhody?

Nemapuje se tak dobre na fyzicky hardware jako proceduralni nebo objektove paradigma, z cehoz plyne urcity overhead. Ale ve svete, kde jednotlive moduly systemu mezi sebou kominikuji po HTTP a data si posilaji v JSON nebo XML se to uz ztrati.

[JS1]

To zni skoro jako pripad "worse is better".

Mne tedy funkcionalni programovani prijde skoro jednodussi, je to spis o zvyku. Obecne se mi zda, ze vyvoj jde smerem od slozitejsiho k jednodussimu (za cenu vyssi abstraktnosti).

Ale naprosto s tebou souhlasim, ze to jde do mainstreamu. Ja jsem byl vuci Haskellu dost skepticky a dnes (jako Haskellista ) uz zdaleka tolik nejsem.

[deda.jabko]

To zni skoro jako pripad "worse is better".

Moc nechapu. Muzes to rozvest?

[kralyk z abclinuxu]

Eh, to bude nejspíše ta slavná úvaha R. P. Gabriela, člověka, který z LISPovského pocitu nadřazenosti zblbnul natolik, že psal pod pseudonymem protiargumenty proti své vlastní úvaze a následně je vyvracel zase pod svým jménem.

V té úvaze víceméně jenom s velkou pompou zjistil, že perfekcionismus má svá negativa a pragmatismus svá pozitiva.

[xxxs]

preco je toto problem?: "naskládat z dostupných balení na skaldě přesně dané cílové množství"

pride mi to ako bezna skladova zalezitost. mozno mi nieco unika, som neprogramator.

[johnyK]

myslim, ze se jedna o tohle:

https://cs.wikipedia.org/wiki/Probl%C3%A9m_batohu

[xxxs]

ak to chapem dobre, NP batoh ma v sebe nejake blizsie neurcene hodnoty, ktore odhadujes, ale skladova evidencia ma presne data. pre uvedene, iba odcitavas zo zasoby, pripadne rozoberas karton.

[xvasek]

Tak si to zkus jenom v hlavě - máš různý počet různě velkých balení a potřebješ napočítat nějaké konkrétní množství tak, abys: 1) rozbaloval až v případě, kdy je to nezbytně nutné a 2) abys na výstupu dal co nejmenší počet krabic. Nakonec přijdeš na to, že to musíš dělat hrubou silou a zkoušet k sobě všechny kombinace.

V normálním světě máš třeba dvě vělikosti balení a to ještě většinou nějaká k sobě soudělná (např. 100ks a 1000ks), takže mozek projde celý ten stavový prostor rychle a "co na tom je", ale představ si, že máš třeba deset prvočíselných velikostí balení, každé v nějakém omezeném počtu.

[hefo]

Ale predsa objem skladu a maximálny počet rôznych druhov balení je nejako zhora limitovaný, čiže sa dá urobiť nejaký "worst-case" odhad náročnosti. Možno že to napriek faktu, že je to NP problém, vyjde pre reálne sklady tak, že ten čas výpočtu bude vždy akceptovateľný, nie?

[xvasek]

Ano, typicky to opravdu vychází jednoduše na pár pokusů, protože celkový počet kombinací jednotlivých balení, kde součet kusů v jednotlivých baleních je menší nebo rovný finálnímu požadavku, bývá velmi malý. Nicméně zákeřný uživatel může schválně naskladnit různá například prvočíselná balení a systém, který to takto počítá, prostě DOSnout, protože složitost roste exponenciálně.

Podobné je to třeba s penězi a bankomatem. Kdybychom zavedli třeba 101-koruny, 103-koruny a 107-koruny a různé podobné například prvočíslené hodnoty a nechali uživatele zadat čásku, kterou si chce vybrat, musel by bankomat projít všechny kombinace těchto bankovek a při narůstajícím počtu nominálních hodnot bankovek by exponenciálně narůstala doba na vyřízení požadavku.

[Bystroushaak]

Nicméně zákeřný uživatel může schválně naskladnit různá například prvočíselná balení a systém, který to takto počítá, prostě DOSnout, protože složitost roste exponenciálně.

Zákeřného uživatele prostě zabanuješ. Nehledě na to, že dokonalý sklad by měl naprosto příšerné lookup časy, protože dostat z něj cokoliv by vyžadovalo přeskládat signifikantní části toho skladu.

Kdybychom zavedli třeba 101-koruny, 103-koruny a 107-koruny a různé podobné například prvočíslené hodnoty a nechali uživatele zadat čásku, kterou si chce vybrat, musel by bankomat projít všechny kombinace těchto bankovek a při narůstajícím počtu nominálních hodnot bankovek by exponenciálně narůstala doba na vyřízení požadavku.

Řešilo by se to stejně jako dneska, tedy že bankomat by měl odevšeho víc a místo aby hledal nějakou prvočíselnou kobinaci, tak by to z největších bankovek složil co nejvýš k tomu číslu a z (kombinace) nejmenších by pak doložil zbytek. A kdyby to třeba možné nebylo, tak pořád nejjednodušší způsob jak tohle vyřešit je zobrazit dialog „zvolte kombinaci bankovek“.

Samozřejmě, jako matematický problém je to fajn a má to asi nějaké své použití, ale v tomhle bych se asi držel víc při zemi. Například skládání proteinů? Komprese?

[xvasek]

Jenomže ten bankomat to tak nedělá. Zkus si z ČS vybrat 1100 korun. Podle tvého algoritmu by měl dát tisícovku a vyhodit tě, ale on ti dá správně pětistovku a tři dvoustovky. Takže buď prochází celý ten prostor, nebo tam má nějakou heuristiku - tady je ještě celkem jednoduchá, pro liché stovky musí použít lichý počet pětistovek.

(Banky, které toto neuměly vyřešit, raději nepoužívají dvoustovky, ha ha.)

[xxx]

Je to primitivni. Nejdriv poresis 1000 a vyssi rady, coz je vzhledem ke skladbe bankovek trivialni. No a na stovky si klidne muzes udelat tabulku o 10 polozkach.

[xxx]

Aha tak ne. Kdo sakra vybira 1100. Musis to prochazet, ale intuitivne bych tipoval, ze pokud se budes vzdycky snazit vlozit nejvyssi hodnotu, tak se ti stane, ze budes muset odstranit maximalne posledne pridanou bankovku.

[Josef Kufner]

Já obvykle vybírám 1900, aby mi dal drobný

Peníze jsou navržené tak, aby se to skládalo snadno a řešení s minimálním počtem bankovek bylo jednoznačné a zřejmé, nejspíš i řešitelné v konstantním čase (resp. lineární s počtem druhů bankovek). Ten bankomat ale má nějak plné zásobníky a není vhodné vydávat to, čeho má málo.

[xvasek]

Algoritmus "dej největší a dorovnávej největšími menšími" funguje pouze v situaci, kdy větší bankovka (balení) rovná se několik menších. To zrovna hapruje na pětistovkách a dvoustovkách, my si v praxi normálně pomáháme triviálně stokorunami.

Každopádně mějme třeba pětikoruny, sedmikoruny a jedenáctikoruny a poskládej si 30 - jak se cítí intuitivní mozek v takovém prostoru, když chce použít dle výše uvedeného algoritmu největší možné bankovky?

[Bystroushaak]

Každopádně mějme třeba pětikoruny, sedmikoruny a jedenáctikoruny a poskládej si 30 - jak se cítí intuitivní mozek v takovém prostoru, když chce použít dle výše uvedeného algoritmu největší možné bankovky?

Přidá si zásobník na jednokoruny.

[xxx]

Ten for je ze potrebujes jednotkovou bankovku, takze pokud mas liche stovky, tak vydas (2k+1) petistovek, tim se ti z 200 stane jednotkova bankovka a zbytek mas to poreseny v linearnim case v zavislosti na poctu ruznych nominalnich hodnot bankovek. (Ale to uz vlastne nekdo napsal)

S prvociselnejma nominalnima hosnotama jsi v <|>, tam ti proste nezbyde nez projit cely stavovy prostor, a ani tak se nemusis dobrat vysledku.

Pro sklad to bude nekde mezi, sice tam budes mit vic 'druhu bankovek', ale zase jestli auto veze 20t nebo 19.9t uz nebede takovej problem. Spis si myslim, ze tam pribudou uplne jine dimenze (jako, ze vsechno jede jinam, jindy, krome hmotnosti velikost, atd...)

[Bystroushaak]

Ano, typicky to opravdu vychází jednoduše na pár pokusů, protože celkový počet kombinací jednotlivých balení, kde součet kusů v jednotlivých baleních je menší nebo rovný finálnímu požadavku, bývá velmi malý.

Myslím že kdysi jsem viděl někde nějaký hezký reálný příklad, kde šlo o řezání tyčí železa. Snaha byla rozřezat jednu tyč o pevně dané délce tak, aby se jednou tyčí uspokojilo co nejvíc zákazníků a zároveň zbývalo co nejmíň odpadu a kusů, které nikdo koupit nechce, protože jsou moc malé. Pokud bys chtěl třeba z jednoho kusu plochého kovu vyřezat laserem něco pro co nejvíc zákazníků, tak to taky potřebuješ co nejvíc nahustit a šetří ti to peníze.

[Josef Kufner]

Složitost roste exponenciálně s velikostí prohledávaného prostoru, nikoliv s ošklivostí dotazů. Výrobci nikdy nebudou reálně vyrábět prvočíselná balení, takže ten prostor bude vždy dost malý na to, aby se to dalo upočítat hrubou silou, i když zákazníci budou chtít ošklivé počty kusů. A i s jednoduchou heuristikou to bude úplně v pohodě a zvládne to i optimalizovat vydávání zboží podle dalších metrik, že například 3 balení po 50 kusech je lepší než 100kusové plus 50kusové balení, neboť to skladník vydá rychleji a líp se mu to bude balit.

[xxxs]

pekna debata. dakujem vsetkym co sa vyjadrili.

[xvasek]

Přesně tak. I když ta definice na české wiki je tak divná, že si nejsem úplně jistý, že vůbec popisuje to, co se nejčastěji myslím pod "problémem batohu", anglická je lepší.

[kralyk z abclinuxu]

Bystroushaak negoval výrok, že u SQL databází se musí někde vytvářet string. Já se s tím ztotožňuji, tak jsem si dovolil to dovysvětlit místo něj.

Osobně nevidím pro účely diskuse rozdíl mezi tím, když se vytváří string a když se vytváří nějaká binární struktura.

[Bherzet]

To ti přijde proto, že se to tu rozštěpilo na více subdiskuzí. Vůči té jedné subdiskuzi, která se odštěpila od #1, to relevantní docela je. Tam xvasek říká, že na úrovni zdrojového kódu programu nechce mít stringy s kódem v jiném jazyce, načež johnyK uvedl, že u SQL databází to jinak nejde. Bystroushaak oponoval, že to nutně platit nemusí, a zmínil kompilaci do bajtkódu (pak se nebudou stringy „mastit“ ani na úrovni nějaké knihovny, jako by tomu bylo v případě těch mnou jinde zmiňovaných builderů – on totiž ty stringy také musí někdo naparsovat). johnyK později uvedl, že to myslel prakticky, Bystroushaak se už nevyjadřuje, ale budeme předpokládat, že to myslel teoreticky, a tím bych toto téma považoval za uzavřené.

[kralyk z abclinuxu]

pak se nebudou stringy „mastit“ ani na úrovni nějaké knihovny, jako by tomu bylo v případě těch mnou jinde zmiňovaných builderů

No jo, ale z toho přece nic neplyne. Mně přijde, že je úplně jedno, jestli ORM vrstva vevnitř mastí stringy nebo nějaké binární bloby. Co na tom záleží?

Co mi přijde relevantní, je otázka, jak moc je možné dělat statickou analýzu a kontrolu nad databázovou interakcí v rámci zdrojáku. U holých SQL stringů to jde špatně, u Prepared Statements, ORM apod. to jde většinou pouze základním způsobem, do určité míry. Ideální by IMHO bylo, kdyby to šlo stejně dobře jako u zrdojáku programu samotného. Všimni si ale, že tohle je otázka úplně ortogonální tomu, jestli se použije SQL nebo ne. Uměl bych si představit formu SQL, nad kterou by ta statická kontrola dělat šla, i kdyby to bylo opravdu pouze v těch stringách ve zdrojáku programu.

Všimni si že třeba u toho MongoDB nemáš SQL a používá se tam binární protokol a "nemastí" se stringy, ale statickou kontrolu nad tím AFAIK nemůžeš dělat o nic líp než třeba nad těmi Prepared Statements.

[Bherzet]

Co mi přijde relevantní, je otázka, jak moc je možné dělat statickou analýzu a kontrolu nad databázovou interakcí v rámci zdrojáku.

Což je úplně paralelní téma, které řešíte s deda.jabko. Všimni si, že ten Bystroushaakův post má číslo #54 a příspěvek, na který reaguje, má číslo #21. Teprve ve #186 v reakci na můj dovysvětlující komentář pro johnyK deda.jabko začal rozvádět novou subdiskuzi, do které se přidal xkucf03, okbob, Josef Kufner a ty. Ve #190 johnyK zareagoval na můj dovysvětlující komentář, pod kterým se mezitím rozjela úplně jiná diskuze, a do toho jsi ve #198 přišel s tím, že „jediný rozdíl je v tom, že ten formát bude jinak vypadat“ (super, přesně o tom byla původně řeč), v reakci na #202 jsem xkucf03 vysvětloval, že žádný kvalitativní skok nikdo nevyzdvihoval, ve #218 jsi řekl, že pro účely diskuze je jedno, jestli je dotaz string nebo binární struktura, v #222 jsem se pokusil znovu vysvětlit, že tady probíhá několik zcela paralelních diskuzí, a teď ve #229 mi řekneš, že relevantní ti přijde otázka, jak to bude se statickou analýzou, když jen z čísel příspěvků je zcela patrné, že o tom v tu danou chvíli řeč prostě být vůbec nemohla a lidi jen mají zmatek v tom, ve kterém sub-sub-sub vlákně se nachází.

[kralyk z abclinuxu]

a do toho jsi ve #198 přišel s tím, že „jediný rozdíl je v tom, že ten formát bude jinak vypadat“ (super, přesně o tom byla původně řeč), v reakci na #202 jsem xkucf03 vysvětloval, že žádný kvalitativní skok nikdo nevyzdvihoval, ve #218 jsi řekl, že pro účely diskuze je jedno, jestli je dotaz string nebo binární struktura

To jsou oboje pouze reiterace toho, co jsem se snažil říct už ve #21 a #26.

když jen z čísel příspěvků je zcela patrné, že o tom v tu danou chvíli řeč prostě být vůbec nemohla

Dobře, a o čem je teda z tvého pohledu řeč v tomto pod-vlákně?

[Bherzet]

Dobře, a o čem je teda z tvého pohledu řeč v tomto pod-vlákně?

V tomhle? To je nějaká meta-diskuze, kde analyzujeme flow diskuze.

Já to zjednoduším (ze svého pohledu), ale budu se opakovat. johnyK napsal, že SQL dotazy musí být stringy. Bystroushaak na to napsal, že nemusí. Na to zareagovalo pár lidí, kde jsem do toho vstoupil já, a přidával se k tomu, že – teoreticky – SQL dotazy nemusí být stringy. johnyK pak upřesnil, že to bral z praktického hlediska a obecně to stringy skutečně být nemusí. Ty pak v #198 říkáš, že na tom přece nezáleží a v čem by bylo lepší, kdyby ten dotaz nebyl string. Nikdo ale neimplikoval, že by tam nějaký fundamentální rozdíl byl, nebo že by to bylo v něčem lepší. Z mého hlediska to byla prostě jen faktická poznámka, upřesnění.

Můj výklad (z vyznění toho tvého komentáře) byl ten, že to chápeš jako by někdo (patrně johnyK, Bystroushaak, nebo já) obhajoval jiné kódování dotazů a očekáváš od nich odpověď a argumenty. Pokud jsi naopak jen rozvíjel diskuzi a chtěl si povídat o (ne)výhodách různého kódování dotazů, pak je chyba na mé straně.

[xkucf03]

+1. Osobně mi sice binární protokoly/formáty nijak nevadí (pokud jsou otevřené) a v některých případech je považuji za lepší volbu (nemusí být vše textové, neuznávám textovost jako nějaké dogma). Ale tady v tom nevidím ten zásadní přínos (proč nahradit textové SQL netextovým SQL).

[Bherzet]

O tom v téhle subdiskuzi (xvasek: „nechci string“ – johnyK: „u SQL to musí být string“ – Bystroushaak: „nemusí“) řeč vůbec nebyla. Ty vlákna jsou fakt peklo, lidi to vůbec neumí používat.

[johnyK]

ano , lide se dost casto nedrzi tematu, ja si myslim, ze to hlavne dela kucera a pak je z toho gulas.

Takze.

Nikdo z nas nemuze v diskuzi nejdriv zacit s tim, ze na 2 strankach presne vymezi oblast platnosti vlastnich argumentu. Proto pak dojde k tomu, ze se neco mysli teoreticky nebo prakticky a zde jsme proste vzajemne odkazani i na intuici a predstavivost diskutujicich. V tomto konkretnim pripade interpretuji napsane nasledovne.

xvasek - nelibi se masteni stringu - a ja to ted precizuji -> xvasek minil stringy, ktere vznikaji napr. pomoci sprintf v nejakem proceduralnim jazyce. Za pomoci toho sprintf se vytvori string , kteremu my rikame 'sql-statement'. Toto bohuzel nikdo explicitne nerekl a i nadale se hovorilo o stringech.

na to nekdo poznamenal, ze to uz se prece nedela. Ja se vsadim, ze ten nekdo mel na mysli nejaky ORM framework, kde se to sprintf nepouziva a ten sql-statement se slozi za pomoci vyvolavani nejakych metod. xvasek to takto nepochopil a znovu se tedy optal, jak se ta databaze dovi co ma delat, kdyz ne pres nejaky sql-statement - ktery i nadale nazyval stringem

Na to jsem ja do toho vstoupil a v domneni, ze je neustale rec o tech sql-statements jsem potvrdil, ze nejaky takovy statement tu byt musi.

Bystroushak chtel patrne take prispet s troskou do mlyna a minil, ze to jde i bez tech statements. Vsimnete si prosim, ze z jeho odpovedi je jasne videt, ze mini ty statements - nabizel jako priklad totiz , ze je mozno se vyhnout tomu sql-parseru. Jenom to co nabidl jsou uplne hovadiny.

ja jsem mu na to odpovedel, ze se myli a opet bez toho abych byl na 105% precizni. Tak se o to pokusim nyni:

Tech nekolik 'velkych' databazi Oracle, DB2, MSSQL, Postgresql, SAPDB, HANA maji jadro, ktere je odkazano na ten bezstavovy deklarativni sql-statement. Bez nej se z tech databazi neda nic vydolovat. Ma to teoreticke a prakticke duvody. Codd zduvodnil, ze ta integrita rel. databaze je zarucena jen tehdy, kdyz se jako dotaz pouzije prave onen deklarativni predpis, odpovidajici rel. algebre. Technicky je te bezstavovost predpoklad, aby to v nejakem silne paralelnim prostredi fungovalo.

Toto vsechno by nas mohlo vest k unahlenemu tvrzrni: U rel. databazi se tedy bez tech statements neobejdeme.

Nyni si muzeme predstavit, ze na harddisk ulozime nekolik csv souboru. Napiseme si sql-parser, ktery bude z tech souboru vytahovat data. A tomu celemu rekneme relacni databaze. To skutece existuje, jmenuje se to mysql csv storage engine. A skutecne, kdyz s vi editorem nakoukneme nejaky ten cvs soubor, tak dokazeme ta data precist bez nejakeho sql-statementu. A nebo si napiseme maly programek, ktery ta data nejak proceduralne precte.

A tim je proveden dukaz,ze vyse uvedene unahlene tvrzeni je chybne. Naopak plati: U relacnich databazi neni vzdy treba nejaky sql-statement, abycho mohli precist nejaka data.

[Bystroushaak]

Bystroushak chtel patrne take prispet s troskou do mlyna a minil, ze to jde i bez tech statements. Vsimnete si prosim, ze z jeho odpovedi je jasne videt, ze mini ty statements - nabizel jako priklad totiz , ze je mozno se vyhnout tomu sql-parseru. Jenom to co nabidl jsou uplne hovadiny.

Mně šlo spíš o to, že principiálně nemusíš „mastit stringy“, ale můžeš cílit přímo na to co je za parserem. To že to některé databáze nepodporují a není to jasně zdokumentované neznamená, že je to něco nemožného, pokud je databáze opensource. Ostatně pokud víš co děláš, můžeš psát klidně do paměťových map procesu (znám lidi co to dělali). A konkrétně přímo ta SQLite to sama o sobě podporuje. Můžeš si tak například napsat vlastní kompilátor do SQLite bytecode a vyhnout se tím všemožným injection problémům, kde musíš řešit escapování SQL jako jazyka, samozřejmě za cenu, že ti vzniknou úplně nové problémy.

[marbu]

a vyhnout se tím všemožným injection problémům, kde musíš řešit escapování SQL jako jazyka

Moment, pro řešení SQL injection stačí prostě použít prepared statements, ne? Escapování je imho blbost a psát si kvůli tomu vlastní kompilátor (jak nazdačuješ) je imho overkill.

[Josef Kufner]

Přesně tak. A na většinu ostatních zde zmíněných „problémů“ stačí rozumný query builder.

[kralyk z abclinuxu]

On to (nejspíše) myslel na obecné/filosofické úrovni, ne na úrovni toho, co musíš dělat jako programátor-uživatel. Ie. implementace Prepared Statements vevnitř escapuje (nutně musí).

[marbu]

implementace Prepared Statements vevnitř escapuje (nutně musí)

Nemusí. Prepared statement vznikde sparsováním textové reprezntace šablony sql dotazu (čímž vznikne jakýsi syntaktický strom, na kterém se dál můžou udělat optimalizace až vznikne strom, který reprezentuje execution plán dotazu). Při použití prepared statementu se už tak znovu nic parsovat nemusí a tím pádem ani nedává smysl nic v ten moment escapovat.

[xkucf03]

Proto právě ten dotaz připravuješ předem, abys ho mohl spustit několikrát s různými parametry. Tzn. ty parametry už pak neescapuješ a nelepíš k dotazu, protože tím by z toho vznikl dotaz nový a ten původně připravený by byl k ničemu.

[kralyk z abclinuxu]

Tzn. ty parametry už pak neescapuješ

Já ne, implementace ano, viz níže...

[marbu]

Já ne, implementace ano, viz níže...

Dovolil bych si zdůraznit, že v kontextu této debaty, kdy Bystroushaak píše o vlastním kompilátoru do SQLite bytecode, se o client-side prepared statements nemá vůbec smysl bavit. Navíc já jsem z databázového světa zvyklý, že pokud mluvím o prepared statements, tak se tím automaticky myslí server-side řešení, tj. co je implementováno přímo v databázi. Z tohoto podledu je pak client-side řešení jen nějaký hack co sedí nad vlastní databází a je ve výsledku jedno, jestli to takto prasí sám programátor nebo knihovna, co používá ...

[okbob]

Existují dva druhy prepared statements - server side a client side. Ty client side escapeují. Jinak to nejde. Server side prepared statements nebo alternativa (parametrized queries) fungují úplně jinak - a je to ukázka jak fungují SQL RDBMS, proto to tady uvedu. Vezmete dotaz, kde na některých místech místo konstant máte placeholdry. V Postgresu $x, v Oracle ?. S placeholdrem se pracuje jako s konstantou určenou v execution time. V planning time se bere jako konstantní, ale v tu chvíli neznámá hodnota. Do prováděcího plánu, se místo konstanty zadrátuje reference na budoucí hodnotu. V execution time (je to totéž co runtime time) se na správné místo uloží parametry, které přijdou od klienta, tak aby byly dostupné zmíněným referencím, a nastartuje se prováděcí plán dotazu. Jelikož prováděcí plán je už vygenerován a nelze jej změnit, tak podvržené hodnoty nemohou vést k očekávanému výsledku útoku.

Původní motivací byla snaha o opakované používání prováděcích plánů - plán pro SELECT * FROM lide WHERE jmeno = 'Pavel' použiji jen jednou pro Pavla, SELECT * FROM lide WHERE jmeno = $1 mohu použít pro libovolné jméno. Na starých CPU z 80-90 let plan cache měla neskutečně efekt, zvlášť když ještě programátoři psali COBOL stylem v SQL, a nebyla paměť pro object cache ORM, jako je to dneska. I na dnešních db když máte dotaz s 40 - a více joinama, tak je nutné dynamicky snížit úroveň optimalizace, nebo je optimalizace (planning time) pomalá - a plan cache má smysl.

[kralyk z abclinuxu]

Ok, ano, ale i u těch server-side statements když pak ORM/DB vrstva volá EXECUTE , stejně musí vyescapovat stringové parametry, ne?

[xkucf03]

To vnitřní API databázového systému se dá implementovat tak i tak. Ale jaký má tahle diskuse smysl? SQL nevyžaduje, aby se to ecapovalo a poslepovalo do jednoho textového řetězce. Funkce v tom interním nízkoúrovňovém API (těsně před vykonáním dotazu) může přijímat text dotazu s otazníky + seznam parametrů. Kdybych to psal já, tak to udělám takhle.¹ Nevidím důvod, proč bych to měl escapovat a slepovat a vzápětí zase parsovat a rozkládat zpět na hodnoty.

_{[1] resp. spíš by se tam předával odkaz na hotový exekuční plán + parametry, protože to SQL s otazníky by se rozparsovalo ještě o krok dřív}

[okbob]

Zatím se většinou používají binární protokoly - a při nich není nutné nic escapeovat - prostě se pošlou 4bajty délky a pak sekvence bajtů s vlastním obsahem. Což se i shoduje s interní reprezentací stringů v databázi. Pro escape není důvod. Co se děje je kontrola kódování a případný překódování do server side kódování - pokud je klient v latin2, a databáze v UTF8, tak se provede překódování do UTF8.

[kralyk z abclinuxu]

Ok, dík za objasnění...

[marbu]

když pak ORM/DB vrstva volá EXECUTE, stejně musí vyescapovat stringové parametry, ne?

K tomu imho není žádný důvod.

Jako dovedu si představit, že tam je nějaká kontrola a ošetření vtupů navíc, ale to jde zcela mimo rovinu sql jazyka a sql injection, o čem se tady bavíme.

[Käyttäjä 11133]

Vytváření SQL kódu v programu mi přijde jako zvěrstvo

A to ještě někdo dělá mimo vyučování ve škole?

[xvasek]

Můžu poprosit příklad někoho, kdo to na nějaké vrstvě nedělá?

[Käyttäjä 11133]

Jasně, když k tomu přidám to co si pšál v komentáři výše... tak ten kdo píše program v Pythonu vlastně taky bastlí nějaké stringy v ASM, že, nebo snad dokonce honí elektrony po sběrnici?!

[ehmmm]

Ja to delam. V pripade slozitejsich selectu s vice joiny a volani stored procedur to je pro me jednodussi, nez patrat, jak to za me udela nejaka knihovna.

A pokud nekdy za me neco takoveho nejaka knihovna udela, tak se v nekterych pripadech stejne radsi nekde bokem podivam, co ji z toho leze za string a jake pri tom databaze pouzije indexy.

[OldFrog {Ondra Nemecek}]

Koukněte na type-safe queries, namátkou

• http://www.jooq.org/
• http://www.querydsl.com/
• https://github.com/my2iu/Jinq
• https://github.com/speedment/speedment

[Bystroushaak]

Podle mého je dále celkem škoda, že se povětšinou jedná o databáze obsluhované jazykem SQL a že se málo prosazují alternativní metodiky. Vytváření SQL kódu v programu mi přijde jako zvěrstvo, podle mého by měl programovací aparát sám svými konstrukcemi zpracovávat data, ne si k tomu mastit nějaké stringy, které mohou dělat kdo ví co.

Někdo to kdysi krásně shrnul jako „cpát si do programu databázový COBOL“.

[johnyK]

následně přechodu na systém, který má ten luxus mít vlastní (nerelační) databázi na míru

kolik % tech zakazniku pozaduje/vyuziva SQL pristup (treba pres Excel)?

[xvasek]

Ze začátku všichni, postupně je to přejde. Ale že to nemá SQL databázi neznamená, že to nejde propojit s Excelem, prostě má vlastní connector. Existuje i ODBC driver, kde je možno nad databází používat nějaký omezený subset SQL. Většinou se to stejně ale řeší nějakým bridge, kde se data vysypou ve formátu, který chce druhá strana, ať je to SQL, soubory, SOAP, XML, whatever. Takže nakonec nikdo o nic (snad) nepřijde.

[johnyK]

Ze začátku všichni, postupně je to přejde.

to jsem si myslel. Mam podobne zkusenosti. Ono tech lidi, co si v nejake firme poskladaji nejaky select statement asi moc nebude, zvlast kdyz to casto nedelaji.

[OndraZX]

To xvasek: To jako pořád pracujete s tou tragédií o které jsme se bavili před už cca 10 lety? Linuxový ERP systém abas od amotIQ

[xvasek]

Tak dokud to obslouží firmy s miliardovými tržbami, tak mi to nepřijde jako tragédie.

[Käyttäjä 11133]

Tak dokud to obslouží firmy s miliardovými tržbami, tak mi to nepřijde jako tragédie.

Jasně, Windows 95 taky není tragédie, protože na tom běží zařízení pro obsluhu výrobních linek obřích korporaci s miliardovými obraty - v dolarech.

[OndraZX]

Já vím, kritika se moc nepřijímá > poté co jsme si Problémy vyřešili paralelně na osobní úrovni, kdy si Amotiq stěžoval na mé nepěkné názory přímo na centrále v CH, jsem už s Abasem ztratil kontakt (byl jsem hodinově "odejit"), ale je zajímavé, že i po 9 letech (naposledy letos v létě) se mi ozývají lidé, kteří mají s Abasem podobné "dobré" zkušenosti. Já jim už pomoci nemůžu, ale přece jsem si jen myslel že za těch dalších skoro 10 let od roku 2009 přece jenom z té historie 70-80 let vystoupíte. No a těch firem s miliardovými tržbami přece jen moc není > ono u velkých firem se to velmi těžko mění a já jsme nikdy netvrdil že minulosti nebyl Abas dobrý systém - naopak. Viz zákazníci > dovolím si tvrdit, že většina je vnucených instalací zahraničníma matkami firem.

PS: za ten "bonz" díky - v tu chvíli to nebylo jednoduché (vrcholila krize, čerstvě narozený syn), ale s odstupem času můžu říct, že to bylo to nejlepší co mě mohlo potkat - já se v té době pořád nemohl rozhoupat odejít.

[xvasek]

Jenomže u vás ve firmě byl problém s tím, že jste si sami stanovili politiku neslučitelnou s normálním životem, tak potom není divu, že se tam nedalo pracovat.

Poměr zákazníků, kteří si systém vybrali sami a kterým byl "vnucen" je asi 1:2 podle počtu, ale naopak někde 5:1 podle obratu. Jinými slovy ti "vnucení" jsou většinou malé filiálky a velké firmy si systém v CZ/SK vybraly samy. Ti velcí pak systém naopak "vnutili" například do Německa nebu UK.

Co se týká "bonzu" - důležité je, že to dobře dopadlo, gratuluji. Každopádně já to nebyl, na vině byla špatná míra Vaší anonymizace (pokud jste chtěl fungovat anonymně) a příliš velká naivita ohledně toho, kdo si to bude číst. A dodnes to nechápu - vyhodili Vás za to, že Vám dodavatel nabídl pomoc?

[OndraZX]

Jenomže u vás ve firmě byl problém s tím, že jste si sami stanovili politiku neslučitelnou s normálním životem, tak potom není divu, že se tam nedalo pracovat.

S tím se dá souhlasit > bohužel to byla také vnucená implementace > přecházeli jsme z Helios Orange, kde vše fungovalo tak jak má, takže averze vůči Abasu byla.

Poměr zákazníků, kteří si systém vybrali sami ....

Nebudu dále komentovat. Zkušenosti jiných hovoří za své.

příliš velká naivita ohledně toho, kdo si to bude číst

No můj zaměstnavatel by si to nepřečetl, kdyby mu někdo nedal impulz, včetně výpisu diskuzí z jiných serveru (no dobrá, tak jsem je nazval "švýcarskými soudruhy co výrobu vedou v Excelu" asi se jich to dotklo > mimochodem ten Excel funguje dodnes.

A dodnes to nechápu - vyhodili Vás za to, že Vám dodavatel nabídl pomoc?

Ne, za moje "blbé kecy" > viz výše > oficiálně za neloajálnost k firmě > švýcaři jsou hodně ješitní

.

Ale nejvíc mě na tom těší, že i po 10 letech mám pravdu (plácají se v tom pořád).

[Odin]

V technicke rovine souhlasim. Jinak mi to prinde, jako kdyby to psal dad. V jednom postu zvladne urazit pana profesora Klause i zidy.

[xkucf03]

+1, tedy až na ten Excel -- ten nemá s relačními databázemi nic společného a je to jen jakási matice, kde na pozicích X a Y (případně třetí rozměr "list") jsou jakési hodnoty... a nebo taky zápisy funkcí odkazující se na jiné pozice... a do toho je namatlané formátování a prezentace dat.

[deda.jabko]

je to jen jakási matice, kde na pozicích X a Y (případně třetí rozměr "list") jsou jakési hodnoty... a nebo taky zápisy funkcí odkazující se na jiné pozice... a do toho je namatlané formátování a prezentace dat.

Tabulkovy procesor je zasadni nastroj v tom, ze jako jeden z mala se prenesl nad klasicke (mnoho let zazite) chapani prace v kancelari a nabizi neco noveho, uzitecneho. (cf. textovy procesor sice usnadnuje tvorbu dokumentu, spell checker, apod. ale samotna tvorba dokumentu zustava stejna, jako by se pouzil treba psaci stroj)

Tabulkovy procesor je koncepcne zajimavy i v tom, ze s relativnim minimem znalosti v nem jen mirne pokrocili uzivatele dokazi zpracovavat data, pricemz nepotrebuji mit vzdelani odpovidajici programatorovi.

to jen jakási matice, kde na pozicích X a Y (případně třetí rozměr "list")

Jenze ty pozice jsou vlastne promenne.

jsou jakési hodnoty...

Promennym jsou prirazeny hodnoty.

a nebo taky zápisy funkcí odkazující se na jiné pozice...

Nebo jsou promennym prirazeny hodnoty vyrazu. Tyto vyrazy mohou odkazovat na jine promenne. (Neni to samozrejme?)

a do toho je namatlané formátování a prezentace dat.

A mame tu i prostredek, jakym vyjadrit vyznam jednotlivych promennych, aby to bylo jednoduche a uzivatelsky privetive.

[SazeVaclav]

Chuck Norris jednou odscroloval v Excelu az na posledni radku.

[Josef Kufner]

To není nijak obtížné.

[Nic]

Jakože zmáčnul ctrl a šipku dolů? To je borec!!!

[SazeVaclav]

Chuck Norris scroluje vyhradne po radcich

[Bystroushaak]

Chuck Norris jednou odscroloval v Excelu az na posledni radku.

Excel specifications and limits;

Total number of rows and columns on a worksheet: 1,048,576 rows by 16,384 columns

To by nedalo zas tak moc práce.

[johnyK]

na beznych desktop systemech ( Chuck pouziva pouze takove) to trva 9.7 hodiny. Chuck to dokazal.

[trekker.dk]

Tak ono je to plné blábolů celé, ta historická vsuvka v podstatě nebere v úvahu posledních ~50 let historických výzkumů.

[Bherzet]

Zda jsou data organizována do tabulek, nebo do dokumentů, je prakticky totéž a jde jen o úhel pohledu (viz mappingy v Elasticsearchi). Stejně tak není fundamentální rozdíl v použitém dotazovacím jazyku a osobně jsou mi query buildery z Mongo/ES driverů sympatičtější než skládání SQL dotazů.

Jediný větší rozdíl je v přístupu. Pokud dokumenty nedodržují striktní schéma, nebo je to schéma příliš divoké, v datech se nelze vyznat. A protože není nutné to schéma vymýšlet dopředu a vytvářet podle něj tabulky, bohužel to tak dopadne snáz než u běžné SQL databáze.

[David Indra]

Souhlas.

[Bystroushaak]

Lehce offtopic, ale pěkný talk; SQLite: The Database at the Edge of the Network with Dr. Richard Hipp

[cezz]

Diky za link, zaujimavy talk, akuram mam pocit ze si mohol usetrit cas a odpustit cely ten rant o Git-e, lebo mi to znelo ako keby git nevedel zobrazit strom commitov a vseobecne mam pocit ze o gite toho moc nevedel okrem toho, ze to nepouziva sqlite. (chapem, ze mozno chcel spropagovat fossil, ale tymto sposobom ma tak akurat odradil)

[Ehm]

To by nebyl argument, kdyby se dva odstavce nevěnovaly vysvětlování a vymýšlení proč nikoho z oponentů nebrat v potaz

[okbob]

Zkuste rekurzi vysvětlit někomu mimo branži :). Co si vzpomínám, tak s tabulkami (byť v sešitě s nalinkovanými okraji) neměla problém moje babička v požehnaném věku 80 let a i ten Excel jsem nějak vysvětlil otci. Kolikrát už není podstatné jak jsou data uložená (např. u clustrovaných tabulek jsou data interně uložená v stromové struktuře, u paměťových tabulek to jsou stromy podle primárního klíče, sloupcové databáze zase ukládají data jako vektory sloupců, atd). Důležitá je vizualizace, a tabulku pochopí každý, kdo se naučil pracovat s jízdním řádem. Na disku je to něco jiného - není nic jednoduššího než sekvenční čtení.

[Bedňa]

Smrť všetkým korí sa dotazujú databáze, namiesto toho, aby si vypýtali konkrétny súbor.

That is all folks.

Dobré ráno v moderných súborových systémoch.

[Bystroushaak]

Souborový systém je jen forma velmi retardované key-value databáze.

[Bedňa]

Souborový systém je jen forma velmi retardované key-value databáze.

Čo je najčastejšia požiadavka ako sa dostať k dátam. To ostatné je už vecou obľúbeného jazyka.

[Bystroushaak]

Jo, ale stojí za zamyšlení proč. Věnoval jsem tomu nějaký čas a v podstatě mi to přijde jen jako věc zvyku, která ve skutečnosti nemá vůbec žádné výhody.

[Josef Kufner]

Prostě je potřeba něco jednoduchého, spolehlivého a univerzálního. Pokud je potřeba pro danou úlohu něco sofistikovanějšího a specializovanějšího, tak se to dá udělat nad tím.

[Bystroushaak]

Prostě je potřeba něco jednoduchého, spolehlivého a univerzálního.

No, ale jakmile nad tím začneš cokoliv stavět, tak se tvoje potřeby naprosto změní. Troufám tvrdit, že v dnešní době něco tak jednoduchého jako FS nepotřebují ani uživatelé, ani programátoři. Mám na tohle téma rozepsáno okolo 50kB textu, tak to zkusím brzo dodělat.

[Josef Kufner]

Další důležitá role souborového systému spočívá ve schování blokových zařízení. Tato celkem nenápadná abstrakce velmi účinně odděluje user-space od hardwaru. Sice se tvoje potřebu mohou změnit, ale přibližovat se k hardwaru obykle není žádoucí (až na výjimky, např. že chceš potvrzení o skutečném dokončení zápisu, nebo vypnout nějaké buffery po cestě).

[marbu]

Troufám tvrdit, že v dnešní době něco tak jednoduchého jako FS nepotřebují ani uživatelé, ani programátoři.

Role filesystému je hlavně v rovině univerzálního api, na kterém se staví prakticky všechno ostatní a která odstiňuje čím dál složitější vnitřnosti, co jsou pod tím. Nedovedu si představit, jak by se mohlo vyplatit zahodit takto elementární a jednoduchý design.

Nicméně chápu, že pro vývoj aplikací může být často výhodnější ukládat data v nějaké databázi nebo použít object storage (např. kvůli škálovaní).

Mám na tohle téma rozepsáno okolo 50kB textu, tak to zkusím brzo dodělat.

Budu se těšit :) Souvisí to nějak s tvým plánem napsat si vlastní objektovou databázi?

[Bherzet]

Nedovedu si představit, jak by se mohlo vyplatit zahodit takto elementární a jednoduchý design.

Mám tohle téma dlouhodobě rozpracované podobně jako Bystroushaak (bavili jsme se spolu o tom, ale každý na to jdeme z trochu jiného úhlu), tak snad se v dohledné době dočkáš odpovědi v podobě hned dvou (sérií?) článků.

[Bystroushaak]

Budu se těšit :) Souvisí to nějak s tvým plánem napsat si vlastní objektovou databázi?

Ne, to je více/méně vedlejší záležitost daná používáním na image založených prostředí jako Self / Smalltalk. I když možná to souvisí tak, že ti to otevře oči co do pohledu nutnosti a užitečnosti filesystému.

[GeoRW]

No a co?

[mirefek]

Mno, s tou Mojžíšovou tabulkou key-value to není tak jednoduche... viz wiki.

[JS1]

Zjevne ta jeho transakce s panabohem nebyla dostatecne ACID.

[kralyk z abclinuxu]

Vsuvka: Dohady o detailech těch příběhů okolo Mojžíše (např. seslání desatera nebo zázračný přechod Rudého moře atd.) jsou celkem bezpředmětné vzhledem k tomu, že celý Mojžíš je s velkou pravděpodobností v zásadě retcon, fikce skompilovaná okolo 5/6. st.přnl., tj. o nějakých 700 let později, než kam je příběh zasazen. Z toho důvodu ty příběhy vesměs nedávají historicky/geopoliticky moc smysl (např. "Útěk z Egypta" je geograficky špatně - tak, jak je popsán by to byl jen přesun z jedné části Egypta do jiné, Jericho byla mrňavá vesnice bez jakýchkoli hradeb, atd.). Dává ovšem poměrně smysl v dobovém kontextu - tj. okupace Izraele Babylónem - a reálie současné vzniku textu jsou celkem přesné. Z toho pohledu jsou knihy Mojžíšovy literárně-náboženský způsob pro část Židů (zejména elitu), jak se vyrovnat s tehdy aktuální nelehkou situací. V tom kontextu se dá na ně jakož i další části dívat jako na disentovou literaturu. Některé věci, jako třeba koncept neviditelného monoteistického Boha, kterého je zakázáno zobrazovat, najednou začnou dávat praktický smysl - ono pro takového židovského anti-babylónského disidenta bylo jistě praktičtější mít jednoho neviditelného boha než muset po kapsách nosit sadu sošek Stejnětak je najednou o dost jasnější, proč oni v těch knihách tak nesnáší modláře a vymezují se proti veškerým cizím bohům - to byla kultura nepřítele-okupanta.

[Dalibor Smolík]

Určitě, ta Mojžíšova tabulka se již tenkrát jmenovala stoneexcel.

[sekacka]

Na počátku byla Tabulka, ta Tabulka bylo u Boha, ta Tabulka byla Bůh. Ta byla na počátku u Boha. Všechno povstalo skrze ní a bez ní nepovstalo nic, co jest.

[JiK]

tak predevsim, ty tabulky byly dve. Jak bys nacpal 10 prikazani na jednu kamenou tabulku? chces to snad tesat oboustrane? A taky, byly to dve tabulky, aby se to Mojzisovi lepsi nosilo. proc by jinak byly lidi stvoreni s dvema rukama?

[Dalibor Smolík]

To ne, ta tabulka byla jen jedna, ta druhá byla záloha, něco jako RAID.

[sekacka]

dokonce to bylo tak, že Mojžíš ty tabulky vzteky rozbil, když zjistil, že část národa začala uctívat tu zlatou koblihu (nebo to bylo tele ?). Bůh sáhnul do trezoru a dal mu backup těch tabulek.

Všechno se mění, jen relační technologie zůstávají. Až jednou přistanou na Zemi mimozemšťané, tak si řeknou - wow - mají také rel. databáze a SQL s tím záhadným joinem ...

[Dalibor Smolík]

A podivnou, něčím zapáchající koblihou.

[JS1]

Nekdo taky tvrdil, ze horici ker byl jenom jinotaj, ze ve skutecnosti si Mojzis dal jointa..

[Dalibor Smolík]

Ne, Hořící keř je seriál z produkce HBO.

[.]

Tak ten úvod je bomba. Naštěstí jsme na ábíčku, kde jsou komentáře vždycky ještě blbější než zápisek, tak nejsi za největšího debila.