Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »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ě.
ž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'.
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ší?
Třeba mongo mastí BSON. V čem je to tak zásadně lepší?Není to SQL... /s
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ž xyPř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.
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
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.
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.
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.
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).
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;
+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é :-)
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í
Od autorů nějakého DBMS to může být relevantní (byť subjektivní) kritika.1 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ší.
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.
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.
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ší.
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ázeTento 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?
Tento pozadavek je od zacatku uplne zcestnyno, nekolik takovych 'relacnich' databazi jeste myslim existuje. Napr. SAP Advantage Database Server.
prijdes o vetsinu tech hezkych vlastnosti, jako je treba optimalizace dotazuale ta optimalizace je tam prece jenom proto, ze by jinak to relacni paradigma smysluplne nefungovalo. U jinych paradigmat ta optimalizace neni vubec potreba.
(č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.)
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.
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.
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.
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ý...
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ě...
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.
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.
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...
"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 objektuCož 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.
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.
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ší...
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.
Ř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.
...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.
Tak jistěže mám, ale nechci to jen tak napsatnezlob 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.
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ůmTy 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...
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ším1 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.2)
[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.
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".
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.
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.
NerozumímEvidentne. 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.
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.
Ano. A pak chceš zamykat něco, co zamykání vůbec nepotřebujeJak 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 => 1000000Ted nechame bezet soubezne upravy i audit:
Thread transfers = new Thread(() -> activity(bank)); transfers.start(); System.out.println(bank.audit()); // vysledek je blbleVysledek 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 spravneAbych 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.
bude v praxi zajímavější řešit nějaký in-memory stav "náhodně" se měnícího systémuNeni 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.
jake problemy mohou vznikat pri pouziti zamkuDomnivam 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.
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 PorscheRelační databáze nejsou zdaleka jen Oracle. Naštěstí.
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í.1 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í
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ý.
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
nebovalid_from
avalid_to
-- a ty se právě mění.1 V případě změny hodnoty pak neaktualizuješ hodnotu v záznamu, ale ukončíš platnostvalid_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í.
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.
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.
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".
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.1 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
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.
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ázeTo 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 budoucnostTo je z pozice NoSQL dost ironické.
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ů).
U databazi, ktere pouzivaji SQl se musi ten string 'nekde' vytvoritA 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.
Použití jazyka SQL je jen jeden ze způsobů reprezentace SQL dotazuDobry postreh, ktery unika prekvapive velkemu mnozstvi lidi.
nechme teď stranou, že ta zkratka znamená Structured Query LanguageMozna 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.
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.
Ale jinak by v tom zásadní rozdíl nebyl.Zustavas s uvahama prilis na povrchu.
Pošleš dotaz + parametryToto 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.
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ě.
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.
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?
Je to úplně stejná úloha, jako zvalidovat XML nebo JSONNe, 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) ...
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.
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.
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.
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.
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.
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.
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?
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.
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 :-)
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).
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?
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í.
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.
Asi jste nepochopil moji analogiiJa 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 spadloTo 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.
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.
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.
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.
technologie, která přežije 10 let - případně se masově rozšíří, tak kvalitu bezpochyby máMS Windows?
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.
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?
SELECT * FROM (SELECT * FROM tab) WHEREsel interně v planning time optimalizuje na
SELECT * FROM tab WHERETypy 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.
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.
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.
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?1 Mi spíš na SQL vadí ty věci, které v něm chybí, než ty, které v něm přebývají.2
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.
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.
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.1 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ě.2 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
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 SQLTo 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.
Pokud by to SQL bylo navrhovano jako protokol, ne jazyk pro lidi, hromada nelogicnosti by z podstaty odpadla.Například?
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.
SQL umožňuje oboje (příklad)Vim, ale to jen dokresluje tu nekoncepcnost, ktera byla zavedena kvuli tomu, aby byl jazyk vhodny pro lidi.
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?kdy jednou je vysledek SELECTu bran jako skalarni hodnota, jindy jako sloupec a jindy jako relace a rozhodnuti zavisi na datech nikoliv metadatechVž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.
Object o = getFoo(); int bar = ((Integer) o).value() + 1;Taky by sis rikal, ze proste takove chyby se stavaji, ze je to jako NPE?
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í.
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.
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.
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.
a pote co vyrobci tech databazi sve produkty preprogramuji se bez tech stringu obejdemeJak? 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?
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í.
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.
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í...
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ů).
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ů.
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.
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.
budu potřebovt iso2kod zeme, tak jej dostanu, systém provede nakoukání do těch referencovaných objektů just-in-timeja 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.
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?
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í?
.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.
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ů.
$CURRENT_YEAR
mi to moc smysl nedává...
To už bych možná byl klidnější i s tim PHP že to je nepodobný čemukoli jinýmu a získané zkušenosti by mi tak byly k ničemu kdekoli jindeto 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.To je těžká otázka
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?
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.
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ů:
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.
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.
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.
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 shelluNemyslim. 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.
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.
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.
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...
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).
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 byznysu1, tak může být ten konzultant, který si to pak i napíše, a tím se ušetří spousta režie2. 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í3 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
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.
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á).
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.
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.).
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.
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" :-)
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žebMozna 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 WSDLFor 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.
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ď sed
em 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í.
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 nePOJO 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.
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ší1 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ě dogma2 a ten, kdo ho nepoužívá, pomalu aby chodil kanálem. Časem, asi už brzy, se něco podobného stane s GraphQL3 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
Anonymizovaná verze:Vypadlo mi z toho
Envelope/Body
.
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.
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
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..
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?
...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?
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.
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.
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-practiceJe 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.
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).
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.
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).
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íhoVš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.
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)
...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 LOOPTohle 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).
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.
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šinou1 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
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.
To zni skoro jako pripad "worse is better".Moc nechapu. Muzes to rozvest?
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?
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.
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.
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.
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.
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í.
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í strukturaTo 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 nemohlaDobře, a o čem je teda z tvého pohledu řeč v tomto pod-vlákně?
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ě.
+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).
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.
a vyhnout se tím všemožným injection problémům, kde musíš řešit escapování SQL jako jazykaMoment, 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.
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.
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.
Tzn. ty parametry už pak neescapuješJá ne, implementace ano, viz níže...
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á ...
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.
EXECUTE
, stejně musí vyescapovat stringové parametry, ne?
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.1 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
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.
Vytváření SQL kódu v programu mi přijde jako zvěrstvoA to ještě někdo dělá mimo vyučování ve škole?
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“.
následně přechodu na systém, který má ten luxus mít vlastní (nerelační) databázi na mírukolik % tech zakazniku pozaduje/vyuziva SQL pristup (treba pres Excel)?
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.
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.
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.
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 čístNo 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
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).
+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.
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.
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 columnsTo by nedalo zas tak moc práce.
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.
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.
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?
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ů.
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.
Tiskni
Sdílej: