MySQL - podmíněný SELECT přes dvě tabulky

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #120 kdy: 18. 10. 2019, 07:16:46 »
To jsem jaksi nespojil já, to jaksi spojili platové předpisy v mnoha firmách.
Jak jsem psal, takový předpis se snadno může změnit.

Tvuj "zlepšovák" takovouto situaci prostě nebude umět zkontrolovat, protože nebude umět správně podchytit, kdo má funkci vedoucího.
Tak, jak jsem to popsal, nebude co kontrolovat, protože do databáze bude přepsána ta definice. Podchycení toho,kdo má funkci vedoucího, bude dané právě implementací té definice.

Tvými zlepšováky jsem nemyslel Tvůj způsob zápisu dotazu, ale Tvůj způsob, jakým jsi chtěl zachycovat zaměstnaneckou strukturu ve firmě. Která byla nesmyslná - viz výš - a tedy není divu, že ostatní ve své argumentaci Tebou navrženou strukturu DB ignorovali a argumentovali rozumnou strukturou DB - proti čemuž jsi se poněkud arogantně ohrazoval.
Pokud máte nějaké zadání, můžete ho rozporovat, že je podle vás špatně, ale nemůžete si ho potichoučku úplně předělat. Struktura DB, kterou jsem popsal, přesně odpovídala zadání, které jsem také jasně napsal. Ostatní mohou zadání klidně rozporovat, mohou navrhnout jiné – ale pokud zadání akceptují ale navrhnou strukturu databáze, která je s tím zadáním v rozporu, je chyba na jejich straně.


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #121 kdy: 18. 10. 2019, 07:19:49 »
Toto pravidlo Filip porušil hned v začátku této diskuse. Nerespektoval realitu databáze, ale respektoval pravidlo určené rozhodnutím. Tím mám na mysli "tbl2 nemusí obsahovat odpovídající záznamy" (realita) vs. "hledáme jen allowed > 0" (rozhodnutí specifické pro jeden jediný pohled).
No jo, když vy si pořád pletete modelování databáze (strukturu tabulek) a dotazování. Tak ještě jednou: SELECT opravdu není součástí modelování databáze. Pokud mi nevěříte, najděte si, jaký je rozdíl mezi DDL a DML, a všimněte si, že SELECT nepatří pod DDL.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #122 kdy: 18. 10. 2019, 17:59:01 »
No jo, když vy si pořád pletete modelování databáze (strukturu tabulek) a dotazování. Tak ještě jednou: SELECT opravdu není součástí modelování databáze. Pokud mi nevěříte, najděte si, jaký je rozdíl mezi DDL a DML, a všimněte si, že SELECT nepatří pod DDL.

Houby si pletu. Vím s jistotou, že pokud můžete modelovat data buďto v souladu s definicí, nebo mimo ni, je vždy preferovaný soulad. Váš INNER JOIN nepřináší nic navíc, pouze omezuje možnosti manipulace s daty.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #123 kdy: 18. 10. 2019, 18:21:37 »
Citace
Jak jsem psal, takový předpis se snadno může změnit....
Takže když změní platební předpis a přidají tam tuto kontrolu, tak kvůli tomu budeš překopávat strukturu databáze a měnit definici toho, kdo je vedoucí?
Teda, s tebou v jednom SW teamu bych fakt pracovat nechtěl - a šéf by Tě nepochválil, že věc na hodinu Ti trvá týden....

Citace
Pokud máte nějaké zadání, můžete ho rozporovat, že je podle vás špatně, ale nemůžete si ho potichoučku úplně předělat.
Pleteš si zadání a strukturu databáze. V zadání je např. schopnost IS zachytit to, že je někdo vedoucí. Nikoli to, jak má DB tuto skutečnost zachycovat. A právě dobrého programátora od špatného odlišuje to, jak dobře je to zadání schopen zobrazit pomocí struktury databáze.

Dobrá implementace zadání se mj. vyznačuje tím, že je schopna do sebe s co nejmenšími změnami integrovat změny a rozšíření zadání. Protože změny zadání jsou každodenní realita - málokteré zadaní tak, jak ho dostaneš, je opravdu správně - a právě takové výjimky (jako např. vedoucí bez podřízených), které ale v reálné praxi nastávají poměrně často, se v zadání zpravidla zapomínají.

Proto pokud kvůli takovým trivialitám, jako např. přidání možnosti vyhodit z oddělení posledního člověka, aniž by se Ti ztratila informace o tom, že je někdo vedoucí, musíš modifikovat strukturu databáze, tak je Tvá implementace zadání prostě špatná.I kdybys dostal explicitně zadáno, že vedoucí je právě ten, kdo má podřízené, i tak je správné řešení funkci a počet podřízených od sebe oddělit, protože jednak to může být chyba v zadání, jednak je velmi pravděpodobné, že i když to je dnes opravdu tak, že to zítra bude jinak.

Ostatní tedy nepředefinovávají zadání, ale počítají s rozumnou implementací tohoto zadání.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #124 kdy: 18. 10. 2019, 18:51:10 »
Jak jsem psal, takový předpis se snadno může změnit....
Takže když změní platební předpis a přidají tam tuto kontrolu, tak kvůli tomu budeš překopávat strukturu databáze a měnit definici toho, kdo je vedoucí?
Teda, s tebou v jednom SW teamu bych fakt pracovat nechtěl - a šéf by Tě nepochválil, že věc na hodinu Ti trvá týden....
Citace

Tento přístup je bohužel typický nešvar internetových návodů. Z velké části jsou examply a rady takové, že se vůbec nesoustředí na návrh, ale jen na magii se selecty. Spousta "dobrých rad" nechává logiku na aplikaci a ze SQL se jen tahají data. O transakcích a konzistenci dat se kde kdo ani nestará, v malém množství se to nepozná - a tak programátoři nemívají žádné návyky.

Nerad generalizuji, ale když mám pohovor s uchazečem a hlásí se ke znalosti SQL, tak se ještě ptám, jestli zná něco jiného než MySQL. Pokud ano, většinou s databázemi umí o řád lépe, než internet-návodoví-samouci na MySQL (Xampp peklo a podobné).

Je určitě potřeba dávat nováčkům rady, a právě toto je to místo. To, co Filip radil byla úzce, specificky funkční rada, bez zamyšlení se nad kontextem. Takové rady pak przní další generace.


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #125 kdy: 19. 10. 2019, 10:20:19 »
Houby si pletu. Vím s jistotou, že pokud můžete modelovat data
Sice to víte s jistotou, ale víte to blbě. Data modelujte pomocí struktury tabulek a omezení. A při vytváření struktury tabulek opravdu JOIN nepoužijete.

Váš INNER JOIN nepřináší nic navíc, pouze omezuje možnosti manipulace s daty.
INNER JOIN navíc přináší přehlednost a srozumitelnost, tím pádem snižuje riziko chyby. Vždyť i vy jste tady ten INNER JOIN pomocí OUTER JOINu psal špatně, než jsem vás na to upozornil – a to se tváříte, jaký jste expert.

Navíc to vaše kritérium, že má být dotaz co nejuniverzálnější, je nesmyslné – a vy sám to víte. Kdybyste tomu svému kritériu opravdu věřil, navrhnete mnohem univerzálnější dotaz, než nějaký OUTER JOIN dvou tabulek. Pořádně univerzální dotaz je CROSS JOIN všech tabulek, teprve ten nijak neomezuje možnost manipulace s daty.

Pleteš si zadání a strukturu databáze. V zadání je např. schopnost IS zachytit to, že je někdo vedoucí. Nikoli to, jak má DB tuto skutečnost zachycovat.
Já si to nepletu. Já jsem napsal, že jedno možné zadání je „vedoucí je definován tím, že má podřízené“. V rozumné definici databázové struktury pak tohle bude kontrolováno, aby nemohl vzniknout vedoucí bez podřízených. Dá se to udělat například tak, že vyjdete přímo z té definice a připravíte si nějaký pohled, který vybere všechny zaměstnance, kteří mají podřízené. Když se v budoucnosti zadání změní, změníte ten pohled. Další možnost je mít na to v databázi příznak a pomocí omezení nebo triggerů zajistit, aby byl vždy nastaven správně.

Dobrá implementace zadání se mj. vyznačuje tím, že je schopna do sebe s co nejmenšími změnami integrovat změny a rozšíření zadání.
Tohle je napsáno hodně obecně, takže to není pravda. Je potřeba umět provést ty změny, které jsou skutečně potřeba. Špatné implementace zadání se totiž mimo jiné vyznačují tím, že jsou přehnaně obecné, přičemž ta obecnost se nikdy nevyužije. A naopak ta obecnost velmi komplikuje skutečné požadované změny, které jsou v takových případech ještě jiného charakteru, než předpokládala ta obecnost. Takže vy si klidně můžete do databáze zavést příznak vedoucího, jenže pak se změní organizační struktura na maticovou, zaměstnanci budou mít organizačního vedoucího a projektového vedoucího, a stejně musíte strukturu měnit.

Ostatní tedy nepředefinovávají zadání, ale počítají s rozumnou implementací tohoto zadání.
Ne, předefinováváte zadání. Pokud zadání zní „vedoucí je ten, kdo má podřízené“, jakmile přijde o posledního podřízeného, podle definice přestává být vedoucím. To zadání vám může připadat divné, můžete ho rozporovat, můžete počítat s jeho změnou. Ale když napíšete „možnosti vyhodit z oddělení posledního člověka, aniž by se Ti ztratila informace o tom, že je někdo vedoucí“, je to v rozporu se zadáním, protože podle zadání dotyčný přestal být vedoucím, ale podle vás dále je vedoucím.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #126 kdy: 19. 10. 2019, 13:01:06 »
Citace
Já jsem napsal, že jedno možné zadání je „vedoucí je definován tím, že má podřízené“.
Což je ovšem zadání s odpuštěním nereálné a tedy nesmyslné. Vedoucí pracovník je termín přímo definován zákonem, tento fakt musí být zachycen v pracovní smlouvě, a jsou zákonem dané možnosti, jak se člověk vedoucím stane a jak jím být přestane. Není možné, aby se z někoho stal "nevedoucí" jen tím, že mu odejde z oddělení poslední zaměstnanec.  I kdyby existovala firma, kde by to dle tvého nelegálního zadání fakt fungovalo, tak možnost, že dřív či později začnou zákon respektovat je natolik reálná, že je blbost na to aplikaci nepřipravit.
Tak se nediv, že si to ostatní Tvé zadání přeložili do reality.
Citace
Špatné implementace zadání se totiž mimo jiné vyznačují tím, že jsou přehnaně obecné, přičemž ta obecnost se nikdy nevyužije
Nu, a proto je třeba, aby ten, kdo navrhuje danou strukturu, o věci něco věděl, jinak není schopen rozlišit obecnost potřebnou od obecnosti "přebujelé".Pokud teda při svém návrhu db ignoruješ legislativu platnou pro daný obor, tak se nediv, že dojdeš k nesmyslným datovým strukturám.

Navíc - viz další odstavec - v normální velké firmě (pro malé se IS zpravidla nedělají) je třeba podchytit v IS daleko více informací (viz další odstavec), takže se do IS firmy hodí daleko flexibilnější datová struktura, než se kterou tady operuješ.
Citace
Když se v budoucnosti zadání změní, změníte ten pohled....... jenže pak se změní organizační struktura na maticovou,
A jsme doma. Vyvrátil sis sám vlastní přístup. Samostatný pohled na vedoucí je evidentně nedostatečný - nebo budeš mít jeden pohled na organizační vedoucí a jiný na projektové vedoucí a třetí na....?
Samozřejmě, že rozumný přístup je mít tabulku organizačních jednotek, a funkcí/rolí v organizačních jednotkách. Nejen vedoucích, ale např. schvalovatelů dovolených, sekretářek, a hromady dalších funkcí/rolí, které je třeba zachytit (např. sekretářkám se posílají pokyny o objednávání kancelářských potřeb atpod.). Tak snadno podchytíš jak stromovou strukturu, tak maticovou, nebo i další pitomosti, co si zrovna ředitel ve firmě vymyslí, aniž bys musel překopávat strukturu databáze. Jen max budeš doplňovat číselníky funkcí.
Tvůj přístup, že do struktury db zakóduješ (navíc ilegální) pravidlo, jak určit vedoucího - a pro další role pak budeš vymýšlet jiné další navzájem nekompatibilní adhoc mechanismy, jak je zachytit a vyhledat, to je cesta do pekel... Samozřejmě, na první pohled je Tebou navržené zachycení fce vedoucího jednoduché. Ale v reálu si o takovej návrh db nabiješ čumec.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #127 kdy: 19. 10. 2019, 13:42:13 »
I kdyby zadání bylo nereálné, neznamená to, že ho můžete tiše ignorovat, vymyslet si své vlastní zadání a tím se řídit. Takovým postupem rozhodně nedojdete k výsledku, se kterým bude zadavatel spokojený. Pokud je termín „vedoucí“ definován v zákoně, můžeme klidně použít pro náš účel jiný termín, třeba „nadřízený“. Mít definované lidi, kteří aktuálně mají podřízené, smysl dává – např. pokud chcete, aby své podřízené o něčem informovali, mimořádně rozdělili prémie o den dřív nebo vytipovali podřízené na školení, nedává smysl informovat o tom někoho, kdo žádné podřízené nemá.

Já jsem nepsal o žádném podnikovém IS, psal jsem o jedné jediné tabulce, která sloužila jenom jako příklad. Nepsal jsem nic o tom, že to má být hotové komplexní řešení. Pouze jsem na tom ilustroval to, že ze struktury tabulek neplyne jediný možný pohled na data, tudíž je nesmyslné odvozovat použití INNER nebo OUTER JOINu z toho, jak vypadá struktura tabulek.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #128 kdy: 19. 10. 2019, 14:26:53 »
Citace
I kdyby zadání bylo nereálné, neznamená to, že ho můžete tiše ignorovat, vymyslet si své vlastní zadání a tím se řídit.
Opakuješ vyvrácené. Nikdo si nevymýšlel vlastní zadání. Jen se navrhla struktura DB tak, aby až se zjistí, že nereálné je, tak se to nemuselo předělávat. Dobrý programátor takovéto věci předvídá.

Citace
...použít jiný termín, třeba „nadřízený....
Ale pak se  na ostatní nezlob, že když použiješ termín a myslíš tím něco jiného, než ten termín znamená, že Ti ostatní nerozumí. To není chyba na přijímači, ale na vysílači.

Citace
nebo vytipovali podřízené na školení, nedává smysl informovat o tom někoho, kdo žádné podřízené nemá.
Jo, takže když někdo nemá ten den podřízené, třeba protože zrovna probíhá organizační změna, tak se nedozví, jaké povinnosti má vůči svým podřízeným, které dostane zítra přiřazené. Právě si prakticky demonstroval, jak je Tvůj příklad defunkční a jak je nutné ty dva fakty (být vedoucí a mít podřízené) oddělit.
Btw. uvědomit si a upozornit na takovéto problémy patří do práce programátora, představa, že Ti někdo dá 100% správné zadání, které jen stačí do písmene přesně implementovat, je mimo.

Citace
Já jsem nepsal o žádném podnikovém IS, psal jsem o jedné jediné tabulce, která sloužila jenom jako příklad.
A tak se pozná dobrý programátor od špatného, jestli řeší věci izolovaně a pak je musí předělávat, nebo od začátku přemýšlí nad problémem v kontextu :-) :-)

Citace
že ze struktury tabulek neplyne jediný možný pohled na data...
Ovšem argumentovat tím, že z blbé struktury tabulek něco plyne, je argumentace špatná. Protože právě blbá struktura databáze je tím, co nabádá ke špatným řešením.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #129 kdy: 19. 10. 2019, 18:41:32 »
I kdyby zadání bylo nereálné, neznamená to, že ho můžete tiše ignorovat, vymyslet si své vlastní zadání a tím se řídit. Takovým postupem rozhodně nedojdete k výsledku, se kterým bude zadavatel spokojený. Pokud je termín „vedoucí“ definován v zákoně, můžeme klidně použít pro náš účel jiný termín, třeba „nadřízený“. Mít definované lidi, kteří aktuálně mají podřízené, smysl dává – např. pokud chcete, aby své podřízené o něčem informovali, mimořádně rozdělili prémie o den dřív nebo vytipovali podřízené na školení, nedává smysl informovat o tom někoho, kdo žádné podřízené nemá.

Podle toho, čemu říkáte "zadání". Pokud jsou to business-požadavky, tak to ještě není zadání. Je známá věc, že business požadavky bývají dost nepřesné, zejména tutéž věc Vám v každé firmě popíše jiný člověk jinak. Každý to vnímá z úhlu svých pracovních povinností. Tedy zadavatel obvykle nedává žádné požadavky, ale spíš popis z jeho pohledu.

Na analytikovi (u malých projektů na programátorovi) je umět tyto požadavky "přečíst" a domyslet všechny situace, na které zadavatel ve svém popisu zapomněl. Obvykle zadavatelé zapomínají na z jejich pohledu nedůležité stavy. Hezký příklad je to rozesílání metodických pokynů - když na jeden den vypadnete z definice "nadřízeného", druhý den novým podřízeným nepředáte požadované informace. Zadavatel nebude chápat, proč se to stalo, když je "zřejmé", že toto neměl na mysli - a Vy to budete fixovat nějakým šíleným hackem nad daty.

To, co jste popsal, je přístup programátorské lopaty (dnes se tomu eufemisticky říká "junior").

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #130 kdy: 19. 10. 2019, 19:40:12 »
Nikdo si nevymýšlel vlastní zadání.

Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené

V aplikaci můžu chtít zobrazit všechny vedoucí, co mají podřízené zaměstnance. Ale také můžu chtít (a je to dost běžné) na jiném místě zobrazit i ty, co (už) žádné podřízené nemají.

Tak buď Miroslav Šilhavý umí vytvořit zaměstnance, kteří zároveň mají i nemají podřízené, nebo si změnil zadání.

Q.E.D.

Podle toho, čemu říkáte "zadání".
Tady v diskusi říkám zadání tomu, co jsem jako zadání napsal.

To, co jste popsal, je přístup programátorské lopaty (dnes se tomu eufemisticky říká "junior").
A jak se říká někomu, kdo si přečte zadání a vzápětí napíše něco, co je s ním zjevně v rozporu, a je mu to úplně jedno? Jak se říká někomu, kdo ostatním pořád vnucuje zapisovat INNER JOIN pomocí OUTER JOINu ale ten příkaz opakovaně píše špatně?

Junior obvykle aspoň ví, že neví. Horší je, když si někdo o sobě myslí, že je expert, ale ve skutečnosti taky neví.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #131 kdy: 19. 10. 2019, 19:52:39 »
Tady v diskusi říkám zadání tomu, co jsem jako zadání napsal.

Což byla pěkně nedomyšlená pitomost na úrovni odpovědi na Racchekův dotaz.

A jak se říká někomu, kdo si přečte zadání a vzápětí napíše něco, co je s ním zjevně v rozporu, a je mu to úplně jedno? Jak se říká někomu, kdo ostatním pořád vnucuje zapisovat INNER JOIN pomocí OUTER JOINu ale ten příkaz opakovaně píše špatně?

Jděte se schladit. V jednom příkladu jsem nedospecifikoval některé stavy, ale účelem bylo upozornit na styl přemýšlení, nikoliv do diskuse napsat definitivní select.

Opakovaně píšu na první otázku odpověď: SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0. V tomto vidíte nějakou chybu?

V těch dalších příkladech je zanedbáno víc věcí, např. když jsme se bavili o VIEW, nemůžu odkazovat na tbl2.id_data (protože výstupem z view už není reference na původní tabulky). Přesto jsem to napsal schematicky, aby bylo zřejmé, co mám na mysli.

Dále jsem zanedbal situaci, kdyby byl sloupec allowed NULLABLE - ale to by bylo významné jen v případě inverze dotazu. Tam jste správně doplnil, že by to bylo potřeba ošetřit - ale to bylo opět mimo scope diskuse. Pointou bylo upozornit, proč je výhodné si postavit select jako outer join, protože přinese univerzalitu (např. ve formě view). Blbinka jako ošetření joinu nebo nullable je už jen technický detail.

Jestli chcete, můžete se dál točit na detailech jako jsou překlepy nebo zjednodušení v zápisu pro účely fóra. Já preferuju diskusi o tom, jak se má k problému přistupovat a proč je jaký postup výhodný. Bohužel, právě tento kontext Vám uniká a úzce se soustředíte na vybraný detail. Ostatně, na toto jsme spolu narazili i při jiných tématech.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #132 kdy: 19. 10. 2019, 23:52:37 »
Citace
Nikdo si nevymýšlel vlastní zadání.
Promiň, už mi mělo dojít, že máš problém porozumět, když člověk se vyjadřuje ve zkratce, a nikoli přísně formálně logicky. Tato věta znamenala:

Nikdo NEMĚNIL tvé zadání, akorát si lidi povšimli chyby toho zadání (která ho činí v praxi nepoužitelným) a tak automaticky přizpůsobili návrh databáze tomu, aby když/až se ta chyba návrhu opraví, nebylo třeba přepisovat půl aplikace.

Už tomu rozumíš, nebo to potřebuješ ještě polopatičtěji? Teda promiň, možná nerozumíš tomu "přepisovat půl aplikace" - tím se myslí, že by s tím bylo zbytečně příliš mnoho práce, samozřejmě se tím nemyslí, že by se musela přepsat každá druhá řádka každého zdrojáku.
Ještě něco potřebuješ vysvětlit?



Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #133 kdy: 20. 10. 2019, 18:17:39 »
V jednom příkladu jsem nedospecifikoval některé stavy, ale účelem bylo upozornit na styl přemýšlení, nikoliv do diskuse napsat definitivní select.
Nikoli. Opakovaně jste se tu pokoušel INNER SELECT přepsat pomocí OUTER SELECTu se spojovací podmínkou přidanou do WHERE, a opakovaně jste tu podmínku do WHERE napsal špatně. Pořád tu píšete o tom, jak je potřeba u začínajících programátorů budovat správné návyky – použít ve WHERE jiný sloupec, než tam má být, s tím, že to v některých specifických případech náhodou bude fungovat, mezi dobré návyky rozhodně nepatří.

V tomto vidíte nějakou chybu?
To, že jste napsal jeden SELECT tak, že by fungoval, neznamená, že jste nemohl udělat chybu v jiném.

Jestli chcete, můžete se dál točit na detailech jako jsou překlepy nebo zjednodušení v zápisu pro účely fóra. Já preferuju diskusi o tom, jak se má k problému přistupovat a proč je jaký postup výhodný. Bohužel, právě tento kontext Vám uniká a úzce se soustředíte na vybraný detail. Ostatně, na toto jsme spolu narazili i při jiných tématech.
Aha, tak použití chybného sloupce v podmínce je překlep a zjednodušení.

Nic mi neuniká. Dávno už jsem vysvětlil, že je ten váš přístup nevýhodný, protože komplikuje a znepřehledňuje kód (o čem svědčí i ten váš „překlep“). Vám uniká, že kód musí být především správný a čitelný, a je nesmysl ho komplikovat s vidinou jakési chimérické univerzálnosti.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #134 kdy: 20. 10. 2019, 18:18:59 »
Nikdo NEMĚNIL tvé zadání
Aha, takže „případ, kdy vedoucí nemá žádné podřízené“ je zcela v souladu se zadáním „vedoucí je definován tím, že má podřízené“. Omlouvám se, této vaší logice opravdu nerozumím – a ani rozumět nechci.