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.
Zobrazit příspěvky
