Příspěvky

2251

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 23:30:25 »

Nehovořím o datovém sloupci, ale o klíči, přes který se to spojuje. Id_data v joinované tabulce nikdy nebude NULL

Hezky jste si vyvrátil svůj předchozí komentář. vy v tom tedy máte děsný hokej… Datový sloupec allow může ve vašem příkladu nabývat hodnot 0, 1 a NULL. id_data nikdy NULL nebude. Spojuje se přes id_data, takže přes to připojíte řádek z druhé tabulky, a v něm může být allow=NULL, což je třeba ten váš případ implicitního nastavení. Samozřejmě může nastat i případ, že se žádný řádek nepřipojí, protože v druhé tabulce neexistuje – to je ale jiný případ, než vámi popisovaný případ allow=NULL.

kromě případu, že k joinu nedojde.

Ne, pořád si to pletete. Neexistence řádku a NULL hodnota v některém datovém sloupci jsou dvě různé věci. Dokonce i kdybyste měl řádek plný samých NULL hodnot (i to jde vyrobit), pořád je to něco jiného, než neexistující řádek. Nenechte se mást tím, že při OUTER JOINu doplní databáze NULL hodnoty na místo těch dat, pro která nemá řádky z druhé tabulky.

2252

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 20:37:28 »

Pak je bude fungovat INNER JOIN, ale LEFT JOIN bude správnější, protože umožní obrátit výběr (selektovat záznamy, které mají allowed=0 nebo nemají odpovídající záznam v tbl2).

Já bych se spíš soustředil na to, aby ten dotaz vracel ty záznamy, které má. Vzhledem k tomu, jak dlouho vám trvalo, než jste zjistil, kde máte chybu, bych nedoporučoval obcházet sémantický INNER JOIN zapsaný v SQL pomocí OUTER JOINu a přidané podmínky jenom proto, že pak dotaz snáze zmodifikujete do jiného arbitrárně vybraného dotazu.

Vzhledem k tomu, že nevíte vůbec nic o řešení doméně, totiž „obrácený výběr“ klidně může znamenat záznamy, které existují a mají allowed=0.

S INNER JOINEM zvládnete obsloužit pouze otázky 1. a 3.

S INNER JOINem samozřejmě zvládnu obsloužit i otázku 2. Už zase si pletete NULL hodnotu v datovém sloupci a neexistující záznam. To máte z toho vašeho čarování s JOINy – kdybyste se smířil s tím, že JOIN slouží ke spojení tabulek a varianta INNER nebo OUTER rozhoduje o tom, jak se bude zacházet se záznamy, které v některé tabulce neexistují, tyhle chyby byste nedělal. Neexistující záznam je něco jiného, než neexistující hodnota v záznamu, před čímž vy neustále svým OUTER JOINem zavíráte oči.

2253

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 16:05:33 »

Já jsem tedy vycházel z prosté úvahy. Mám sloupec "allowed" (povoleno), který může být 0 (nepovoleno) nebo >0 (povoleno). Pokud daný sloupec neexistuje (je NULL), nenaváže se, pak "povoleno" není určeno => tedy "není povoleno" = "je zakázáno".

Mít strukturu databáze, kde hodnoty >= 1 znamenají „povoleno“ a hodnoty 0 a NULL znamenají zakázáno, není dobrý nápad. Každý stav by měl být reprezentován právě jednou hodnotou.

2254

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 16:02:06 »

To sice ano, ale pak jsi to hned zabil nesmyslným trváním na tom, že jeden způsob negace je lepší.

Odkazujete na komentář, kde jsem znova zopakoval, že zadání musí upřesnit tazatel.

Potřebovali. Protože je třeba odlišit variantu záznam existuje, ale je NULL a záznam
 neexistuje

Než bylo do SQL zavedeno klíčové slovo JOIN, nikdo to podle vás nepotřeboval?

Proto nepovažuji Miroslavovy dotazy za chybu - prostě předpokládal standardně rozumně navrženou databázi.

Přečtěte si ty dotazy ještě jednou a pozorněji – zejména se zaměřte na to, který sloupeček testuje na NULL.

A pokud tedy opravdu na distinkci výše nezáleží, pak použití INNER/OUTER JOINu je na programovacím stylu. Jak Tvůj argument (že v raritním případě může dojít k sémantické odlišnosti), tak Miroslavova (že se to lépe upravuje při změně sémantiky) je validní, ale Miroslavův argument je daleko více "z praxe".

Já si myslím, že o praxi vypovídá to, proč JOIN bez upřesnění je zkratka zrovna pro INNER JOIN. Že by to bylo proto, že je to nejčastější použití? Snadnost úpravy při jedné specifické změně sémantiky je irelevantní, existují miliony jiných změn sémantiky, kvůli kterým budete muset třeba přidávat další tabulku do dotazu nebo dotaz úplně předělat.

Ne, ty jsi uváděl "Bydlí v Praze" a tvrdil jsi, že jediná přirozená negace je "Bydlí mimo Prahu". Což prostě v totmo případě opravdu není pravda. Když odpovím na "Bydlíš v Praze?" "Ne", tak tím nijak nevylučuji to, že jsem digitální nomád a nebydlím nikde.

Já vím, co jsem uváděl – a vy si to můžete přečíst.

Ne, jen ses o to snažil a ten příklad se Ti fakt nepovedl. A na základě toho špatného příkladu si vyvozoval obecný princip, "že není správné použít přesnou negaci", který měl zpětně podpořit ten Tvůj špatnej příklad.

Můj příklad se povedl, nepovedl se váš příklad, který vznikl jako volná variace na téma mého příkladu. Nevyvozoval jsem z toho ani vámi uváděný obecný princip, pouze jsem upozorňoval na to, že přístup Mirka Šilhavého „všichni se na to dívají jako programátoři, a pokud explicitně uvedete příklad, kdy se na to někdo dívá jinak, stejně se na to dívá špatně, protože by se na to měl dívat jako programátor“.

Ale vidím, že celý váš komentář sestává jen z toho, co jsem údajně měl napsat, ale ve skutečnosti jsem to nenapsal. Vyvracet to znova u každého vašeho komentáře mi připadá zbytečné, považujme to za výchozí stav a tím pádem je zbytečné, abych na vaše komentáře reagoval.

2255

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 11:48:16 »

Filipova teze, že se to myslelo určitě takhle, a kdo to pochopil jinak je blbej - to je přesně případ programátorský arogance, kterej vede na zbytečnou práci.

Jasně, a ta moje teze se projevuje tím, že jsem byl první, kdo tu explicitně napsal, že to zadání je nejednoznačné, napsal jsem oba dva možné významy a také které řešení se pro který případ použije.

3) Když už bych si měl z těch variant vybrat, tak na tezi, že LEFT JOIN umožňuje zachytit obě sémantiky, takže je lepší použít ho a podle dohovoru s klientem popř. poupravit detail má něco do sebe. INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

Můžete se na to dívat tak, že INNER JOIN je jen speciální případ OUTER JOINu. Ale to bychom pak INNER JOIN nepotřebovali, že… Protože se ale INNER JOIN sémantika v reálném světě vyskytuje docela často, a napsat ji pomocí OUTER JOINu není úplně triviální, jak ukazují četné neúspěšné pokusy Miroslava Šilhavého, máme pro ten speciální případ také speciální syntaxi.

Ovšem pokud se to vztáhne na reálný problém "kdo kde bydlí", tak opravdu ti, co nebydlí nikde, nebydlí ani v Praze. Tendle příklad se Ti Filipe fakt nepovedl.

Já jsem ale neuváděl tenhle případ. Já jsem uváděl příklad „bydlí v Praze“ × „bydlí mimo Prahu“. Ten, kdo nebydlí nikde, nebydlí ani v Praze ani mimo Prahu.

5) "Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“
je hezká ale trochu chabá snaha se z toho nepovedeného příkladu vykroutit. O sémantice negace se v zadání vůbec nemluvilo.
A protože Tebou "axiomovaný" způsob jen jeden z dvou možných způsobů negování původního dotazu, tak jde o krásný případ důkazu kruhem: Negace vypadá takto a proto je správné moje chápání negace a proto negace vypadá takto.

Negace nebyla v zadání, negaci sem přitáhl až Mirek Šilhavý. Já jsem jenom uváděl příklady, že v přirozeném jazyce znamená negace často něco jiného než prostý doplněk množiny. Často pozitivní ani negativní množina neobsahuje NULL hodnoty, s těmi se zachází speciálně – proto je to tak implementováno i v SQL.

2256

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 10:25:32 »

Hm, měl jsem pocit, že sem chodí spíš programátoři, než markeťáci. Pokud někdo tvoří SQL, musí se umět vyjadřovat i přijímat informace exaktně, ne jako vechtr. Možná jsem se zmýlil.

Programátoři ovšem musí psát programy podle zadání, ne podle toho, jak se jim to hodí. Když dostanou zadání „vytvoř dva dotazy, jeden s allowed = 0 a druhý s allowed > 0“, nemohou se jen tak rozhodnout, že ty dotazy nejsou programátorsky inverzní a předělat je.

2257

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 10:15:41 »

Co na to říct? Opak "bydlí v Praze" je "neplatí, že bydlí v Praze", tedy "nebydlí v Praze".
Do "nebydlí v Praze" i v běžné řeči patří ti, co nebydlí nikde (např. turisté), nikoliv jen obyvatelé ostatních obcí v ČR.

Logika přirozeného jazyka je jiná, než programátorská logika. Když marketingu vyjde, že lidi v Praze je potřeba oslovit jiným dárkem, než lidi ve zbytku ČR, bude chtít dvě opačné sady záznamů – obyvatele Prahy a obyvatele z jiných obcí, než je Praha. Bezdomovce, u kterých neznají adresu, opravdu řešit nebudou. Když bude ředitel firmy chtít seznam vedoucích, kteří mají plat přes 50 tisíc, vzpomene si později, že chce i seznam vedoucích, kteří mají méně než 50 tisíc. Nebude chtít seznam vedoucích, kteří mají méně než 50 tisíc, a všech ostatních zaměstnanců.

Mimo jiné proto byla do databází zavedena hodnota NULL, protože v reálném životě se běžně stává, že můžete záznamy rozdělit do několika disjunktních skupin, a pak máte záznamy, které nepatří do žádné skupiny. A ty záznamy, které nepatří nikam, se neberou v úvahu u množinových operací jako je doplněk. Proto se NULL chová tak divně s operátory, že když použijete operátor a jeho negaci, pro NULL hodnoty není splněna ani jedna podmínka, třeba x = 0 OR x != 0 pro NULL hodnoty není vyhodnoceno jako pravdivý výraz.

je to právě proto, aby bylo snadné psát v SQL dotazy z reálného života a nebylo nutné používat ty vaše komplikované konstrukce.

2258

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 08:47:01 »

Ha! Tak jsme u podstaty věci. Pane kolego, tak toto je školácká chyba na úrovni druhé, třetí lekce práce se SQL.

Omlouvám se, nebylo mým cílem nachytat vás na švestkách. Ale chytil jste se krásně.

pak SQL pak platí, že:

Já jsem ale nepsal o SQL. Psal jsem o tom, jaké je obvykle zadání, jak to vnímají lidé, jak to obvykle plyne z logiky věci. Když budete mít zadání „vypište všechny uživatele, kteří bydlí v Praze“, bude k tomu obvykle inverzní zadání „vypište všechny uživatele, kteří bydlí mimo Prahu“, ne „vypište všechny uživatele, kteří bydlí mimo Prahu nebo nebydlí vůbec“. Abyste se v tom neztratil, tu podmínku jsem vám přímo slovně napsal.

Musíte s NULL počítat! […] Aby toto mohl vývojář opominout, musel by být sloupec allowed nastavený NOT NULL a nemohlo by platit že záznam v pravé tabulce může či nemusí existovat.

Výborně, takže to, že allowed může být nullable, vás napadlo.

Tím bych naši diskusi uzavřel. Je zřejmé, že SQL rozumíte, doplníte si za domácí úkol studium NULL a to, jak je s ním potřeba v SQL počítat.

Pane kolego, domácí úkol tady bude dělat někdo jiný, totiž vy. Když už teď víte, že allowed může být nullable, a také víte, že NULL hodnotám je potřeba věnovat zvláštní péči, projdete si všechny ty INNER JOINy zapsané pomocí OUTER JOINu, které jste do diskuse napsal. Teď už snad konečně uvidíte tu školáckou chybu, kterou jste ve všech svých příkladech udělal. Tu chybu opravíte a zapamatujete si, že je dobré používat nástroje k tomu, k čemu jsou určené – takže když je sémantika příkazu INNER JOIN, je rozumné to napsat pomocí INNER JOINu a ne to znepřehledňovat OUTER JOINem, zejména, když neumíte správně napsat podmínku, která ten INNER JOIN definuje.

2259

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 01:11:26 »

Během optimalizace dotazu dojde query planner ke stejnému prováděcímu plánu. Jak už jsem psal výše, pro planner je totožné INNER JOIN a LEFT JOIN WHERE right.id IS NOT NULL (nebo right.id > 0, protože to implikuje IS NOT NULL). To je taková hodně základní optimalizace.

O optimalizaci dotazu tady ale nikdo nemluví. Jde o sémantiku dotazu, o to, jak ho chápe vývojář.

Řeknu to možná lapidárně: pokud někde vidím INNER JOIN, očekávám vazbu 1:1-N. Pokud vidím LEFT JOIN, očekávám 1:0-N. Tato čitelnost je důležitá, zejména když se na SQL příkazy dívá někdo cizí, nebo i sám po nějaké době.

To je ale váš problém, že SQL dotazy čtete jinak, než všichni ostatní. Znamená to, že od zápisu INNER JOIN očekáváte něco, co vám nemůže zajistit, a když pro zápis INNER JOINu používáte OUTER JOIN, musíte správně napsat tu podmínku, která z toho udělá INNER JOIN. Což se vám zrovna tady v diskusi ještě nepovedlo. Řečeno s Cimrmanem – ten váš kód je sice hůř čitelný, ale zato v něm děláte chyby.

...výhodou LEFT JOINU je i to, že se dá dotaz invertovat jen změnou podmíny:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0

a k tomu je opakem:
SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed = 0 OR allowed IS NULL

Jak vidíte, první část se nemění, mění se pak jen podmínka. Toho s INNER JOINEM nedosáhnete.

Až na to, že normální lidi považují k dotazu „dej mi všechny záznamy, které mají podřízený záznam allowed > 0“ za inverzní „dej mi všechny záznamy, které mají podřízený záznam s alowed = 0“ (za předpokladu, že alowed > 0 a alowed = 0 jsou k sobě inverzní).

Viz výše příklad s obrácením funkce. Left join je rozhodně lepší zápis, čitelnější a vyjadřuje strukturu dat. Výsledek bude stejný, ale kdokoliv se na to podívá, pochopí líp, co od toho očekávat.

Když je to tedy lepší a čitelnější zápis, proč ho tu pořád píšete špatně?

2260

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 05. 10. 2019, 22:01:35 »

Pokud psal, že v tbl2 může, ale nemusí být odpovídající záznam, zdá se, že obě situace jsou zcela validní.

To ovšem platí pro každý JOIN. Rozhodující pro volbu INNER/OUTER JOIN je to, zda neexistence záznamu v podřízené tabulce znamená, že záznamy ve výsledné sadě být nemají, nebo zda znamená, že jsou data pro ten záznam neznámá (a mají tedy být nahrazena NULL hodnotami).

V takovém případě je lepší použít OUTER JOIN a podmínku psát do WHERE. Přesně tam patří podmínky, je to mnohem čitelnější než zahazovat řádky v rámci JOINU.

Stará syntaxe skutečně psala všechny podmínky do WHERE. Nová syntaxe s klíčovým slovem JOIN ale rozlišuje podmínky na ty, které se používají pro spojení tabulek, a na ty, které filtrují výslednou sadu záznamů. Ta hranice není úplně ostrá, takže se najdou případy, kdy mohou být logické obě varianty. Což ale není tento případ, tady je podle zadání jistě podmínka omezující výslednou sadu jenom allowed > 0 – všimněte si, že je uvedena v zadání samostatně, žádná jiná podmínka u ní už není. Jenom jako poznámku na konec přidal Racchek informaci, že tbl2 nemusí obsahovat všechny záznamy z tbl1, což je informace o tom, že je nutné řešit, zda použít INNER JOIN nebo OUTER JOIN. Akorát už nenapsal, která varianta platí.

Vaše tvrzení, že je to mnohem čitelnější, myslím dobře vyvrací ta skutečnost, že jste právě kvůli té vaší variantě zápisu udělal v dotazu chybu. Výhoda zápisu INNER JOIN přes klíčové slovo (INNER) JOIN je v tom, že už nemusíte specifikovat, jak se pozná, že podřízený záznam neexistuje. Ta podmínka plyne přímo z INNER JOINu a databáze ji tam přidá sama – a na rozdíl od vás správně.

Podle Vaší logiky by bylo přípustné i SELECT ... FROM tbl1 INNER JOIN tbl2 ON tbl1. id_data = tbl2.id_data AND allowed > 1. I to by dalo stejný výsledek, ale to už je ultraprasárna.

Ne, nic takového jsem já nepsal. Nicméně pokud by zadání bylo formulované jako „vybrat z tbl1 všechny záznamy, kde v tbl2 existuje odpovídající záznam s allowed > 0“, považoval bych to za ten hraniční případ, kdy jsou možné obě varianty. Protože buď tabulky spojíte a pak sadu filtrujete, nebo můžete tabulku spojit s filtrovanou tabulkou – a v té mnou uvedené formulaci už je to spíš to druhé.

2261

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 05. 10. 2019, 21:15:10 »

Nechť si Racchek vybere podle požadavku, ale ať tam proboha necpe INNER JOIN, když tomu struktura neodpovídá. Myslím, že je důležité si utvořit správné návyky a určitou štábní kulturu.

Ano, je důležité si utvořit správné návyky a určitou štábní kulturu. Takže pokud Racchek má požadavek vybrat z tbl1 ty záznamy, které jsou v tbl2 a mají tam allowed > 0 má krystalicky čistý učebnicový příklad na INNER JOIN, tak by ho tak také měl napsat. Tomu vašemu příkladu s INNER JOINem psaným pomocí OUTER JOINu, který je navíc špatně, ať se zdaleka vyhne. (Ten váš příklad by vyžadoval splnění jednoho předpokladu, který ale v zadání uveden není.)

Vážně by mne zajímalo, jakou ještě lepší strukturu, než tuhle, byste si pro INNER JOIN představoval.

2262

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 05. 10. 2019, 20:54:11 »

Nejsou, SELECT * FROM tbl1 INNER JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0
vrátí absolutně to samé jako SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE tbl2.allowed > 0.
To druhé je ale čistší vzhledem k zadanému popisu dat (v pravé tabulce může a nemusí být odpovídající záznam).

Četl jste komentář, na který reagujete? Napíšu o SQL dotazech, ale o tom, co Racchek požaduje.

Vstupní data:

Kód: [Vybrat]

SELECT * FROM tbl1
-------
id_data
-------
100
101
102

SELECT * FROM tbl2
-------
id_data|allowed
100    |0
101    |1

Racchekovo zadání je sporné. Nevíme, zda pro výše uvedený příklad požaduje tuhle sadu výsledků („tbl2.id_data nemusí obsahovat všechny data v tbl1.id_data“):

Kód: [Vybrat]

-------
id_data
-------
101
102

Nebo tuhle sadu výsledků („vybrat pouze to, co v tbl2 je jako allowed >0“):

Kód: [Vybrat]

-------
id_data
-------
101

To první je OUTER JOIN, to druhé je INNER JOIN. Která varianta zápisu příslušného JOINu se použije je detail, podstatné je vědět, co Racchek chce. Už to chápete?

2263

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 05. 10. 2019, 19:31:26 »

No právě protože "co kdyby" je dané jako premisa (tbl2 nemusí obsahovat záznamy), je určitě lepší praxe provést OUTER JOIN a omezení dát do WHERE. Do JOINU patří definice struktury dat, do WHERE podmínky. Pokud by použil INNER JOIN, tak by část podmínky de facto přesunul do klauzule JOIN. To se nedá doporučit, SQL by mělo být čitelné a podmínky by měly být zejm. ve WHERE. Kdyby se do budoucna rozmyslel a podmínku chtěl přeformulovat (užít např. IS NULL / IS NOT NULL), nefungovalo by to, protože řádky by zahodil JOIN.

Ne, tady jde především o sémantiku. O to, jestli chce Racchek provést sémanticky INNER JOIN – tedy ve výsledné sadě nebudou záznamy, které nemají záznam v tbl2, nebo chce provést sémanticky OUTER JOIN – tedy ve výsledné sadě budou takové záznamy, které v tbl2 vůbec nejsou, nebo tam jsou a allowed mají větší než nula. Jsou to významově dva různé dotazy, dávají jinou sadu výsledků, a nejprve si tazatel musí rozhodnout, kterou sadu výsledků chce, teprve pak je možné říci, který dotaz k těm výsledkům vede.

2264

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 05. 10. 2019, 17:29:54 »

Myslím, že sémanticky správný je LEFT JOIN.

Co je sémanticky správně musí napsat Racchek. Napsal „vybrat pouze to, co v tbl2 je jako allowed >0“, to by vedlo na INNER JOIN. Pak ale doplnil, že tbl2 nemusí obsahovat všechny záznamy z tbl1 – že uvedl tuhle informaci by vedlo na OUTER JOIN, ale je možné, že ji doplnil jen z neznalosti „pro jistotu, co kdyby to na řešení mělo vliv“.

Pro Raccheka – ke spojení několika tabulek do jednoho dotazu se v SQL používá klauzule JOIN, která má různé varianty. Je to úplný základ relačních databází, bez znalosti JOINu nemá smysl se s relační databází o cokoli pokoušet. Pokud se chcete naučit základy používání relačních databází, kupte si o tom nějakou knížku, vyšlo jich dost.

2265

Vývoj / Re:Naučení se asynchronnímu programování

« kdy: 05. 10. 2019, 15:13:36 »

Když to vezmete podle používanosti jazyků, je JavaScript asi nejrozšířenější jazyk, kde je asynchronní programování od začátku integrální součástí jazyka. Spousta programátorů ho i kvůli tomu nenávidí… Dnes už se dá JavaScript používat i pro backend, osobně bych ho tam ale nepoužil na nic víc, než nějaké prototypy. Ale na webovém frontendu JavaScript kraluje a asynchronně se tam programuje odjakživa.

Pokud by vás zajímal spíš backend, tam se vyznám nejvíc v Javě. Pokud byste chtěl něco low-level, existuje projekt Netty pro asynchronní síťovou komunikaci, staví se nad tím webové servery i klienti, streamovací servery a spousta dalších protokolů. Pokud něco na vyšší úrovni, osobně bych doporučil Micronaut Framework – myslím, že je to Spring budoucnosti. Interně používá také Netty, interně má obsluhu požadavků asynchronní, ale umí to skrýt a pracovat v synchronním režimu.

Ale záleží, který směr vás zajímá – já jsem uvedl konkrétní implementace, ostatní uvedli koncepty jako message broker nebo fronta událostí. „Asynchronního“ toho na programování může být dost, ten pojem pokud vím neoznačuje nic konkrétního.