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

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #105 kdy: 14. 10. 2019, 20:57:14 »
:) jenže to jsme pořád u toho samého. Pokud si "SELECT * FROM tbl1 LEFT JOIN tbl2" vyčleníte do VIEW, můžete pak s tím samým VIEW pracovat všemi způsoby. Třeba tím, že do WHERE doplníte allowed > 0, nebo že tbl2.id_data IS NULL.

Je pochopitelně dost účelné mít jedno VIEW a pracovat s ním jen v podmínce.
Když jsem psal o tom CROSS JOINu všech tabulek, myslel jsem to ironicky. To nebyl návod, že se k tomu máte snažit přiblížit…

Já osobně dělám pohledy na data, která dávají nějaký smysl. Pokud dává smysl spojit tbl1 s existujícími řádky v tbl2, udělám si na to pohled. Pokud dává smysl ty tabulky spojit, ale ignorovat neexistenci záznamů v tbl2 a prostě místo nich doplnit NULL hodnoty, udělám si na to pohled. Pokud dávají smysl oba dva přístupy, udělám dva pohledy. Vy za každý vytvořený pohled platíte, nebo proč je pro vás tak důležité, že je ten pohled jeden a ne dva? Navíc se ty dva pohledy používají v různých situacích, takže se mi to krásně oddělí. Dost možná ty pohledy budou mít i jiné sloupce nebo dokonce připojené jiné další tabulky. Kdyby to vše nacpal do jednoho pohledu, budu muset navíc v aplikaci k tomu jednomu způsobu použití muset všude přidávat podmínku (proč? přesně k tomu přece mají sloužit pohledy).Nedej bože, abych u jednoho způsobu použití potřeboval něco změnit – jiné sloupečky, připojit další tabulku… Pak stejně budu muset projít celou aplikaci, najít všechna místa, kde se ten pohled používá, zjistit, že je to způsob použití 1 nebo 2 a pak to budu moci konečně slavnostně rozdělit na dva různé pohledy.

Obzvlášť zábavné to vaše řešení bude tehdy, když optimalizátor nezvládne nad tím vaším view udělat predicate push a vy donutíte databázi přečíst celou velkou tabulku, ze které by vám normálně INNER JOIN vybral pár záznamů podle indexu.


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #106 kdy: 14. 10. 2019, 21:15:41 »
Pokud dávají smysl oba dva přístupy, udělám dva pohledy. Vy za každý vytvořený pohled platíte, nebo proč je pro vás tak důležité, že je ten pohled jeden a ne dva? Navíc se ty dva pohledy používají v různých situacích, takže se mi to krásně oddělí. Dost možná ty pohledy budou mít i jiné sloupce nebo dokonce připojené jiné další tabulky.

Pokud mám interpretovat určitou vazbu dat, je výhodné mít jeden pohled, třeba i se všemi sloupci, co se nabízejí. V následném selektu pak sloupce omezím jen na ty, které potřebuji. Tím, že v pohledu jsou k dispozici, nic neztratím, ani na výkonu.

Pokud potřebuji mít připojené další tabulky, není nic neobvyklého nad existující pohled postavit další, s dalším joinem.

A proč na to nechci mít dva oddělené pohledy? Inu protože pohledy mají zvyšovat přehlednost - čím méně jich je, tím snáz se revidují. Pokud mi dva pohledy opakují tu stejnou vazbu a jen přidávají podmínku, nedává to moc smysl. Ale kdybych to přeci jen chtěl mít, tak si nejprve udělám pohled interpretující strukturu dat, a teprve nad něj postavím speciální pohledy s filtry. V praxi se setkávám s pohledy s filtry jen v případě, kdy slouží k omezení přístupu k datům (uživatel nedostane práva na samotné tabulky, ale dostane práva jen na zafiltrovaný pohled).

Typicky, mám-li hlavičku dokladu a k ní navázaných 0-nekonečno položek dokladu, pak použiju OUTER JOIN a uložím to jako view. Nad ním pak mohu stavět agregáty (např. count položek). Ze stejného pohledu mi vypadnou jak doklady bez položek, tak doklady s položkami. Po agregaci u bezpoložkových dokladů získám count=0. Nebo použiju agregáty nad parcelami dat. Tento přístup je mnohem výhodnější, než abych v aplikačním kódu zvlášť selektoval doklady s položkami, zvlášť volal agregační funkce, a zvlášť selektoval doklady bez polože.

V případě stromu oprávnění potřebuji od zkoumaného uzlu směrem nahoru vyhodnocovat přístupové oprávnění. Pokud není určeno (OUTER JOIN navrátí v klíči NULL), je to indikátor k tomu přejít k dalšímu nadřazenému uzlu a vyhodnotit dědění práv. Pokud bych měl mít jedno view na existující práva a druhé na neexistující práva, musel bych joinovat tyto dvě views proti sobě. Pokud to mám v jednom provedu JOIN téhož view sama na sebe.

Prostě příkladů, kdy se to hodí je bezpočet a naopak málo případů je, kdy to může být škodlivé.

Na druhou stranu si uvědomuji, že spousta programátorů není schopna napsat select s více než třemi joiny, neumějí joinovat tabulku sama na sebe, zpracovávat parcely dat atd. atd. Právě proto si myslím, že je dobré radit jaké možnosti SQL nabízí a trpělivě vysvětlovat, že SQL optimalizace je vždy úspěšnější, než logiku programovat v aplikaci. Příklad Raccheka je přesně z toho ranku, kdy se dá poradit jednoduché řešení (INNER JOIN), ale i ukázat, že existuje i jiný, a možná zajímavý přístup k věci.

INNER JOIN bych používal zejména tam, kde se neočekává, že odpovídající záznam neexistuje - např. zmíněné číselníky, nebo pravá strana dynamické vazby (tbl1 LEFT JOIN tbl_vazba INNER JOIN tbl_hodnoty - první join nemusí nastat, ale pokud nastane, tak pravý už je obligatorní).

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #107 kdy: 14. 10. 2019, 21:47:41 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat. Zároveň můžu mít nadefinováno, že každý zaměstnanec má svého vedoucího, to je pořád stejná struktura dat, pohled „zaměstnanci se svým vedoucím“ bude velmi podobný. Stejná struktura tabulek, stejná data, JOIN stejné tabulky do sebe sama – ale dva různé významy, dva různé pohledy, a možná dva různé JOINy, podle toho, jak bude vyřešen ředitel firmy, zda i u něj bude dodrženo pravidlo, že každý má vedoucího.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #108 kdy: 14. 10. 2019, 21:53:24 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat.

Přesně naopak. 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í. Tedy jak existence, tak neexistence navázaného záznamu je významná. Struktura dat je pro oba záměry shodná, liší se jen v podmínce filtru.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #109 kdy: 14. 10. 2019, 22:57:22 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat.

Přesně naopak. 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í. Tedy jak existence, tak neexistence navázaného záznamu je významná. Struktura dat je pro oba záměry shodná, liší se jen v podmínce filtru.


e3k

  • ***
  • 217
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #110 kdy: 15. 10. 2019, 20:15:12 »
Pořád se slepě řídíte strukturou tabulek a neberete v úvahu význam dat. Pokud záznamy s neexistující vazbou nemají žádný význam, nemá smysl vytvářet nad nimi pohled, abyste je následně při každém použití toho pohledu musel odfiltrovat. Já jsem nepsal o pohledech, které přidávají jednu podmínku, ale o pohledech, které reprezentují různá data. Např. pokud je vedoucí zaměstnanec definován tím, že má podřízené, nemá smysl vytvářet si pohled s vedoucími, který bude obsahovat i ty, kteří žádné podřízené nemají, a ty z něj pak při každém použití odfiltrovávat.
sakra Filip vyser sa uz na to. proste mozes dostat listu zamestnancov ktory uz nemaju nadriadenych a tam bude NULL. NULL neni nic zle da sa s tym dalej pracovat. ide o to co chces robit.

Přesně naopak. 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í. Tedy jak existence, tak neexistence navázaného záznamu je významná. Struktura dat je pro oba záměry shodná, liší se jen v podmínce filtru.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #111 kdy: 15. 10. 2019, 21:16:48 »
sakra Filip vyser sa uz na to. proste mozes dostat listu zamestnancov ktory uz nemaju nadriadenych a tam bude NULL. NULL neni nic zle da sa s tym dalej pracovat. ide o to co chces robit.
Myslím, že o tom, jak psát správně SQL dotazy, by neměli poučovat lidé, kteří mají problém zapamatovat si zadání o třech větách. Napíšu, že vedoucí je definován tím, že má podřízené, načež Miroslav Šilhavý začne řešit, co když vedoucí nemá podřízené. Napíšu, že každý zaměstnanec má svého nadřízeného (což může platit i pro ředitele, který může být v databázi nadřízeným sám sobě – může to být vhodné, protože pak není potřeba řešit výjimky, kdo mu bude schvalovat dovolenou apod. ) – a e3k objeví, že je možné to řešit i tak, že ne každý má svého nadřízeného.

Zadání vám klidně může připadat hloupé, pak je ale potřeba s tím zadáním polemizovat, ne si potichoučku řešit něco jiného. Takže za sebe bych to uzavřel, že než začnete řešit, jaký typ JOINu je nejlepší, je nejprve potřeba si pořádně přečíst zadání.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #112 kdy: 15. 10. 2019, 23:08:53 »
Citace
Napíšu, že vedoucí je definován tím, že má podřízené...
Promiň, ale toto je typický antipattern. Právě proto, že může být vedoucí oddělení, kde nejsou zaměstnanci (ale např. platově je v třídě vedoucích atd....) - spojuješ do jednoho příznaku dva nesouvisející fakty.
 
Stejnej nesmysl je vynucovat že každý má svého nadřízeného: kde jaksi Tvůj rovnák na vohejbák (že ředitel bude nadřízen sám sobě) nebude dobře fungovat, protože např. dotaz na počty podřízených jednotlivých lidí bude dávat (bez patřičných ošetření komplikujících dotazy a navíc snadno opomenutelných) špatné výsledky, protože ostatní vedoucí sami sebe nepovedou.

Stará známá poučka návrhu databází praví: "zachycujte realitu". Jakmile si začneš v struktuře DB vymejšlet "geniální zjednodušení", dřív nebo pozdějc si o ně "nabiješ hubu".

Takže se moc nedivím, že ostatní Tvé "zlepšováky" pro návrh db ignorovali a radši přemýšleli nad rozumnou strukturou databáze, tedy takovou, kde vztah "být nadřízen" zachycuje opravdu nadřízenost a vedoucí je opravdu vedoucí, a nikoli vedoucí, co má alespoň jednoho podřízeného.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #113 kdy: 16. 10. 2019, 13:19:38 »
Zadání vám klidně může připadat hloupé, pak je ale potřeba s tím zadáním polemizovat, ne si potichoučku řešit něco jiného. Takže za sebe bych to uzavřel, že než začnete řešit, jaký typ JOINu je nejlepší, je nejprve potřeba si pořádně přečíst zadání.

To je o tom, jestli chcete být programátorská lopata, která nechce rozumět reálnému prostředí a co jí není vyspecifikováno do puntíku, tak to ignoruje. Nebo jestli chcete program (včetně SQL) opravdu navrhovat. Pak musíte přemýšlet o krok dál.

Zadání bylo naprosto přesně zadané: struktura dat byla dána tím, že "v tbl2 může a nemusí existovat odpovídající záznam", zatímco podmínka dotazu byla dána "allowed > 0". Naopak vy jste ze zadání naprosto nadbytečně dovodil, že OUTER JOIN se dá redukovat na INNER JOIN.

e3k

  • ***
  • 217
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #114 kdy: 16. 10. 2019, 19:53:36 »
Myslím, že o tom, jak psát správně SQL dotazy, by neměli poučovat lidé, kteří mají problém zapamatovat si zadání o třech větách.
ano je to tu zaspamovane a neda sa to uz citat.

Napíšu, že vedoucí je definován tím, že má podřízené, načež Miroslav Šilhavý začne řešit, co když vedoucí nemá podřízené. Napíšu, že každý zaměstnanec má svého nadřízeného (což může platit i pro ředitele, který může být v databázi nadřízeným sám sobě – může to být vhodné, protože pak není potřeba řešit výjimky, kdo mu bude schvalovat dovolenou apod. ) – a e3k objeví, že je možné to řešit i tak, že ne každý má svého nadřízeného.
ja som skor riesil Vasu fobiu z NULL hodnot spomenutu niekde vyssie.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #115 kdy: 16. 10. 2019, 19:59:57 »
ano je to tu zaspamovane a neda sa to uz citat.

Toto je zrovna hned v prvním postu:

Citace
Potřeboval bych provést SELECT dotaz nad jednou tabulkou tbl1.id_data, který je podmíněn jinou tabulkou tbl2,
tedy z tbl1.id_data vybrat pouze to, co v tbl2 je jako allowed >0
S tím, že tbl2.id_data nemusí obsahovat všechny data v tbl1.id_data

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #116 kdy: 16. 10. 2019, 20:19:44 »
Právě proto, že může být vedoucí oddělení, kde nejsou zaměstnanci (ale např. platově je v třídě vedoucích atd....) - spojuješ do jednoho příznaku dva nesouvisející fakty.
Ty dva nesouvisející fakty (vedoucí a platová třída) jste spojil vy.
 
Stejnej nesmysl je vynucovat že každý má svého nadřízeného
Někdy je to naopak velice praktické. Můžete organizačně (ne databázově) s tou rolí nadřízeného spojit určitá oprávnění, např. schvalování dovolené. A pak nedojde k situaci, že si ředitel nemůže vzít dovolenou, protože mu ji nemá kdo schválit.

nebude dobře fungovat, protože např. dotaz na počty podřízených jednotlivých lidí bude dávat (bez patřičných ošetření komplikujících dotazy a navíc snadno opomenutelných) špatné výsledky, protože ostatní vedoucí sami sebe nepovedou
Větší banalitu už tam nemáte?

Stará známá poučka návrhu databází praví: "zachycujte realitu".
A proto mi tu ve svém komentáři vysvětlujte, že mám ignorovat realitu a databázi raději navrhnout jinak.

Mimochodem, ten můj model databáze zachycující realitu je problematický z jiného důvodu. Další poučka říká, že není vhodné databázi modelovat těsně podle pravidel daných realitou, pokud jsou ta pravidla daná rozhodnutím. Protože se to rozhodnutí může změnit.  Takže pokud mi někdo řekne, že u nich ve firmě je nadřízený definován tím, že má podřízené, budu zvažovat porušení pravidla „modeluj realitu“ právě proto, že ta definice nadřízeného je daná rozhodnutím a může se změnit.

Takže se moc nedivím, že ostatní Tvé "zlepšováky" pro návrh db ignorovali
Já jsem žádné zlepšováky nenavrhoval, právě naopak – já jsem psal o standardním zápisu INNER JOINu pomocí INNER JOINu. Naopak jsem proti zlepšováku Miroslava Šilhavého s tím, že pro INNER JOIN použije zápis pomocí OUTER JOINu a spojovací podmínku přidá k filtrovacím podmínkám do WHERE.

To je o tom, jestli chcete být programátorská lopata, která nechce rozumět reálnému prostředí a co jí není vyspecifikováno do puntíku, tak to ignoruje. Nebo jestli chcete program (včetně SQL) opravdu navrhovat. Pak musíte přemýšlet o krok dál.
Když píšete o sobě, pište raději v první osobě než v druhé. Navíc vy jste ignoroval i to, co do puntíku specifikováno bylo.

Zadání bylo naprosto přesně zadané: struktura dat byla dána tím, že "v tbl2 může a nemusí existovat odpovídající záznam"
Ano, tím je dána struktura dat. Struktura dat se popisuje pomocí DDL, zatímco JOIN je součástí SELECTu, tedy DML. Je hloupé pokoušet se JOINem určovat strukturu dat, protože tím strukturu nezměníte.

zatímco podmínka dotazu byla dána "allowed > 0"
Jsem rád, že jste konečně zaregistroval, jak byla dána podmínka. Ano, přesně takhle. Proto je také přesně tahle podmínka ve WHERE. A nefunguje to jen náhodou, jako ve vašem případě, ale vždycky, pro jakoukoli podmínku. Co když se podmínka změní na allowed IS NULL? V mém postupu se jenom změní podmínka ve WHERE a bude to dál fungovat. Vy byste v takovém případě (možná) zjistil, že jste použil špatný JOIN a že ho musíte opravit.

Naopak vy jste ze zadání naprosto nadbytečně dovodil, že OUTER JOIN se dá redukovat na INNER JOIN.
Nikoli, ten INNER JOIN je v zadání napsaný: „vybrat pouze to, co v tbl2 je …“. To naopak vy jste zcela nadbytečně odvodil, že zrovna v tomhle konkrétním případě se i OUTER JOIN bude chovat stejně jako požadovaný INNER JOIN.

ja som skor riesil Vasu fobiu z NULL hodnot spomenutu niekde vyssie.
Zkuste příště řešit reálné věci a ne vaše výmysly. Žádnou fóbii z NULL hodnot nemám, jenom jsem připomněl, že NULL je speciální hodnota, která má svůj význam, a není vhodné její význam měnit.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #117 kdy: 16. 10. 2019, 20:28:24 »
Já jsem žádné zlepšováky nenavrhoval, právě naopak – já jsem psal o standardním zápisu INNER JOINu pomocí INNER JOINu. Naopak jsem proti zlepšováku Miroslava Šilhavého s tím, že pro INNER JOIN použije zápis pomocí OUTER JOINu a spojovací podmínku přidá k filtrovacím podmínkám do WHERE.

Až na to, že žádná podmínka se nemusí přidávat. Stačí tam pouze WHERE allowed > 0. Kde je ta přidaná podmínka?

Jsem rád, že jste konečně zaregistroval, jak byla dána podmínka. Ano, přesně takhle. Proto je také přesně tahle podmínka ve WHERE. A nefunguje to jen náhodou, jako ve vašem případě, ale vždycky, pro jakoukoli podmínku. Co když se podmínka změní na allowed IS NULL? V mém postupu se jenom změní podmínka ve WHERE a bude to dál fungovat. Vy byste v takovém případě (možná) zjistil, že jste použil špatný JOIN a že ho musíte opravit.

Ano, přesně tak. Mohu chtít vyselektovat záznamy WHERE allowed IS NULL, což se bude v OUTER JOINU platit ve dvou případech: a) pokud nedojde k joinu, b) pokud k joinu dojde a ve sloupci allowed bude NULL. Je už na programátorovi, aby si určil, jakou situaci hledá. Podle toho naformuluje podmínku buďto jako prosté WHERE allowed IS NULL, což by dost možná dávalo smysl (práva nejsou upravena ani existencí řádku, nebo ani hodnotou allowed), případně by mohl podmínku rozšířit na WHERE tbl2.id_data IS NOT NULL AND allowed IS NULL.

S Vaším inner joinem se může jít klouzat, nedokáže dohledat řádky, které v tbl2 nemají odpovídající záznam.

Logik

  • *****
  • 1 022
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #118 kdy: 17. 10. 2019, 12:02:16 »
Citace
Ty dva nesouvisející fakty (vedoucí a platová třída) jste spojil vy.
To jsem jaksi nespojil já, to jaksi spojili platové předpisy v mnoha firmách. Třeba jen tak, že vedoucí nesmí mít platovou třídu menší než..... Tvuj "zlepšovák" takovouto situaci prostě nebude umět zkontrolovat, protože nebude umět správně podchytit, kdo má funkci vedoucího.

Citace
A pak nedojde k situaci, že si ředitel nemůže vzít dovolenou, protože mu ji nemá kdo schválit.
Evidentně o firemní struktuře (velké firmy) toho moc nevíš. Ředitel, jakožto statutár, si vůbec dovolenou nebere, protože není zaměstnanec firmy, ale pracuje dle smlouvy o výkonu funkce (mandatorní smlouvy). Právě proto, protože zaměstnanec je někomu podřízen, zatímco ředitel ne - a tedy mnoho paragrafů ze zákoníku práce zde vůbec nedává smysl - např. ředitel dovolenou nemá. Právě proto, že je nesmysl, aby si ji sám schvaloval.

Další věc je, že je naprosto normální, že dovolené neschvaluje pouze nadřízený, ale i další pověření lidé (např. zástupci nadřízených, ale běžní jsou i další schvalovatelé, např. sekretářky vedoucích), takže Tvoje jednoduché pravidlo pro schvalování dovolené je nesmyslné, v IS je třeba mít možnost explicitně jmenovat lidi, kteří dovolenou schvalují. Takže ty řídké případy, kdy statutár má zároveň pracovněprávní vztah (to se děje v podstatě jen u malých s.r.o., kde jednatel zároveň pro s.r.o. pracuje - a takové zpravidla nemívají IS) jde bez problémů vyřešit tímto mechanismem a není třeba databázi plevelit nesmyslnou rekurzivní výjimkou, že je člověk nadřízený sám sobě (přičemž to platí jen pro jednoho konkrétního člověka).

Zatřetí pak IS, který by zakázal schválit dovolenou člověku bez nadřízeného by byl vadný. I taková situace totiž může ve firmě nastat: např. zaměstnanec vracející se z mateřské dovolené, kdy zatím bylo jeho oddělení bylo zrušeno, takže není zařazen ve firemní struktuře. Pro takové lidi musí existovat nějak stanovený schvalovatel (a toto právo by samozřejmě měl mít i řiditel) - který pak kupodivu může schvalovat i dovolenou řiditeli v pracovněprávním poměru.

Takže Tvůj nastolený problém je umělý a naprosto neodpovídá požadavkům praxe z mnoha důvodů....

Citace
Větší banalitu už tam nemáte?
Jistě, špatný počet zaměstnanců v sestavách je banalita, zatímco schvalování dovolené pro člověka, který si dovolenou nebere, to je nutnost....Pokud Ti přijde jako banalita to, že v jakémkoli algoritmu vypisující stromovou strukturu firmy budeš muset řešit výjimku, aby se Ti algoritmus nezacyklil, tak bych tebou navržené databáze fakt nechtěl používat.
Citace
že mám ignorovat realitu a databázi raději navrhnout jinak.
Realita je, že člověk je nadřízený sám sobě? Odkdy?
Realita je taková, že člověk, jmenovaný do funkce vedoucího, není vedoucím, i když zrovna třeba v jeho oddělení zrovna teď nejsou zaměstnanci?
Máš "zajímavý" "smysl pro realitu".
Citace
Já jsem žádné zlepšováky nenavrhoval
No, nečekal, jsem, že to budu muset vysvětlovat polopatě, ale holt....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.






Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #119 kdy: 17. 10. 2019, 12:22:13 »
Já bych ještě citoval Filipa:

Citace
Další poučka říká, že není vhodné databázi modelovat těsně podle pravidel daných realitou, pokud jsou ta pravidla daná rozhodnutím.

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