reklama

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

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #30 kdy: 06. 10. 2019, 09:02:37 »
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.

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.

Už poměrně chápu, proč jsme se ve vedlejší diskusi nemohli shodnout na výkladu zákona.

reklama


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #31 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #32 kdy: 06. 10. 2019, 10:18:19 »
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.

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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #33 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #34 kdy: 06. 10. 2019, 10:28:51 »
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.

To nerozporuju.

Celou dobu tvrdím, že zápis přes OUTER JOIN je univerzální vzhledem k informacím co máme, protože podmínku, ať ji vymyslíte, jak ji vymyslíte, půjde dát pouze do WHERE. Pokud použijete INNER JOIN, bude to fungovat jen v případech, které popisujete Vy.

reklama


Logik

  • *****
  • 749
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #35 kdy: 06. 10. 2019, 10:59:07 »
1) Původní zadání je nejednoznačný - právě proto, že normální lidi nemyslej v nulách a jedničkách, tak tím mohou myslet obojí.
Tabulka s allowed může znamenat "právě Ti, co mají dovoleno" (to bývá častější), ovšem i "Ti, co mají právo nějak upraveno oproti jinde získanému standardnímu stavu".
V prvním případě pak dává smysl negace s INNER JOINEm, v druhém s LEFT JOINEM.
 
2) Dobrej programátor proto neiplementuje půl dne něco nejasnýho, ale nejprve se zeptá. 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.

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.

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

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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #36 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #37 kdy: 06. 10. 2019, 11:56:01 »
INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

Udělal jsem na to schválně test (na PostgreSQL). Podle očekávání ve všech třech případech si to SQL zoptimalizovalo na tutéž náročnost:

root=# EXPLAIN SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE allowed > 0;
                        QUERY PLAN
----------------------------------------------------------
 Nested Loop  (cost=0.00..2.07 rows=1 width=8)
   Join Filter: (tbl1.id_data = tbl2.id_data)
   ->  Seq Scan on tbl2  (cost=0.00..1.02 rows=1 width=8)
         Filter: (allowed > 0)
   ->  Seq Scan on tbl1  (cost=0.00..1.02 rows=2 width=4)
(5 rows)


root=# EXPLAIN SELECT * FROM tbl1 INNER JOIN tbl2 USING (id_data) WHERE allowed > 0;
                        QUERY PLAN
----------------------------------------------------------
 Nested Loop  (cost=0.00..2.07 rows=1 width=8)
   Join Filter: (tbl1.id_data = tbl2.id_data)
   ->  Seq Scan on tbl2  (cost=0.00..1.02 rows=1 width=8)
         Filter: (allowed > 0)
   ->  Seq Scan on tbl1  (cost=0.00..1.02 rows=2 width=4)
(5 rows)


root=# EXPLAIN SELECT * FROM tbl1 LEFT JOIN tbl2 USING (id_data) WHERE tbl2.id_data IS NOT NULL AND allowed > 0;
                        QUERY PLAN
-----------------------------------------------------------
 Nested Loop  (cost=0.00..2.07 rows=1 width=8)
   Join Filter: (tbl1.id_data = tbl2.id_data)
   ->  Seq Scan on tbl2  (cost=0.00..1.02 rows=1 width=8)
         Filter: ((id_data IS NOT NULL) AND (allowed > 0))
   ->  Seq Scan on tbl1  (cost=0.00..1.02 rows=2 width=4)
(5 rows)

Logik

  • *****
  • 749
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #38 kdy: 06. 10. 2019, 13:12:41 »
Citace
Jasně, a ta moje teze se projevuje tím, že jsem byl <a href="https://forum.root.cz/index.php?topic=21909.msg317937#msg317937" rel="nofollow" class="bbc_link" target="_blank">první, kdo tu explicitně napsal
To sice ano, ale pak jsi to hned zabil nesmyslným trváním na tom, že jeden způsob negace je lepší.

Citace
. Ale to bychom pak <tt class="bbc_tt">INNER JOIN</tt> nepotřebovali,
Potřebovali.
 Protože je třeba odlišit variantu záznam existuje, ale je NULL a záznam
 neexistuje, což je případ, který se vyskytuje hodně zřídka a je normální DB navrhovat tak, aby pokud možno toto nebyl rozdíl - protože defakto oba stavy jsou reálně pochopitelné jako "neurčeno" a

- pokud mají sémantickou odlišnost, pak musí být explicitně vysvětlena, struktura není samovysvětlující. Navíc se s takovou databází pracuje špatně, právě kvůli výsledným problémům s negací. V takovém případě je daleko vhodnější sémantickou hodnotu: záznam je,ale je "nejasný" zachytit nikoli hodnotou NULL, ale nějak jinak.Samozřejmě asi se dá najít speciální příklad, kdy takový návrh bude mít opodstatnění, ale to je takový výjimka, že točit se na něm při řešení evidentně triviálního případu je poněkud demagogické.
- a pokud nemají sémantickou odlišnost, pak je chyba návrhu, že jedna skutečnost může být postihnuta různými stavy v DB.
Proto nepovažuji Miroslavovy dotazy za chybu - prostě předpokládal standardně rozumně navrženou databázi. Pokud naopak na těchto drobných odlišnostech bazíruješ, tak by to mělo být pro Tebe důvod k zamyšlení, nad jak kvalitními strukturami DB jsi zvyklý pracovat.

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

Citace
Já jsem ale neuváděl tenhle případ. Já jsem uváděl příklad „bydlí v Praze“ × „bydlí mimo Prahu“.
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.

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


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #39 kdy: 06. 10. 2019, 13:25:50 »
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á 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".

Pokud by byl sloupec nazván "disallowed", "prohibited" či "restricted", pak bych NULL hodnotě přiřkl význam opačný => "není zakázáno" = "je povoleno".

Uznávám, že tato úvaha nemusí v praxi platit, např. pokud by se uplatňovala vícestupňová evalvace práv (pokud nenajdu oprávnění na své úrovni, podívám se o úroveň výš, výš, až nahoru) - v tom případě by měl NULL svůj význam. Ale i v tom případě OUTER JOIN poslouží líp, než INNER JOIN.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #40 kdy: 06. 10. 2019, 15:31:14 »
INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

Udělal jsem na to schválně test (na PostgreSQL). Podle očekávání ve všech třech případech si to SQL zoptimalizovalo na tutéž náročnost:
Sorry že se do toho pletu, ale

  • Dotaz explicitně specifikoval MySQL, kde to může dopadnout jinak (a nejspíš dopadne, viz bod dva).
  • Uvedené výsledky nevypovídají naprosto nic o tom jak se "dotaz zoptimalizuje", protože explain byl proveden na pididatabázi s tak malým počtem řádků, že z toho postgres prostě udělá 2x full scan + nljoin. Což je charakteristická vlastnost postgresu.


Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #41 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.

Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #42 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.

robin martinez

  • *****
  • 840
  • Have you hugged your toilet today?
    • Zobrazit profil
    • Null Storage
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #43 kdy: 06. 10. 2019, 16:31:04 »
...
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.

presne tak
One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man.

I do Linux, Hardware and spaghetti code in PHP, Python and JavaScript

Logik

  • *****
  • 749
    • Zobrazit profil
    • E-mail
Re:MySQL - podmíněný SELECT přes dvě tabulky
« Odpověď #44 kdy: 06. 10. 2019, 17:07:57 »
 :'(
Citace
Odkazujete na komentář, kde jsem znova zopakoval, že zadání musí upřesnit tazatel.
A to, že jsi jednou napsal rozumnou věc jako znamená, že jsi v dalších příspěvcích nemohl začít tvrdit blbiny???
Citace
Snadnost úpravy při jedné specifické změně sémantiky je irelevantní,
Pokud je to změna sémantiky, která se dá očekávat, protože je v tomto smyslu nejasné zadání, tak to rozhodně irelevantní není. Dobrý programátor toto kritérium při designu programu zohledňuje: je to jedna z poměrně klíčových vlastností dobrého kódu.

Citace
Já vím, co jsem uváděl – a vy si to můžete přečíst.
Evidentně furt nevíte, co jste napsal za nesmysl. Prostě pokud někdo řekne, že chce všechny pražáky, a pak řekne,že ty ostatní, tak rozhodně nechce explicitně vyloučit ty, co nikde nebydlí. To jste jednoznačně popíral a to je prostě nesmysl.A pokud jste to popírat nechtěl, tak se holt smiřte s tím, že se neumíte vyjadřovat a pochopili jsme to tu prostě jinak, nežjste chtěl. Vzhledem k tomu, že je nás víc, tak asi nebude chyba na přijímači.
Btw. i Vaše ostatní příklady byly nesmyslné: např. příklad s vedoucím, tak tam jednou bude chtít vedoucí, co mají plat nad 50. A podruhé bude chtít ostatní vedoucí. Tedy všechny vedoucí, kteří nespadli do první kategorie - např. tedy i tyu kterých není plat znám. Rozhodně by Vás šéf nepochválil, kdybyste mu jednoho šéfa, u kterého není v IS plat znám,nedodal. To, že nebudou chtít běžné zaměstnance je nesmyslný argument - být vedoucím a mít plat je ortogonální kritérium,selekce podle jednoho nemá s tím druhým nic společného.

A koneckonců i v případě samotné Prahy jste vlastně sám se sebou ve sporu, protože přiznáváte, že: "Bezdomovce, u kterých neznají adresu, opravdu řešit nebudou.". ŘEŠIT NEBUDOU. Tedy nikoli, že jim nechtějí dát dárek - tedy že explicitně chtějí null hodnoty vyloučit, jak tvrdíte.

Obecně jsou dvě možnosti: buď si člověk možnost "třetí hodnoty" uvědomuje, pak ji zpravidla řeší explicitně. Daleko častější je ovšem to, že si tuto možnost vůbec neuvědomuje, a negací nějakého kritéria myslí: "Všechny ostatní".

Citace
proč JOINbez upřesnění je zkratka zrovna pro INNER JOIN. Že by to bylo proto, že je to nejčastější použití? Snadnost
Vzhledem k tomu, že standard SQL je všechno, jen ne úsporný - a preferuje ukecanost a relační čistotu před praktičností, tak to je špatný argument. Např. většina políček v db je dnes not null, a přeci je to nutné explicitně uvádět.

A btw..., když si tak horoval za pravou sémantiku SQL dotazů, tak zrovna sémantika NULL je v SQL pěkně zmršená(jeden z mnoha problémů např. https://www.oreilly.com/library/view/sql-and-relational/9781449319724/ch04s04.html)Furt se tu oháníte "pravou sémantikou SQL" a jak se jí mají lidé držet. Jenže ona ta "původní sémantika" SQL byla vytvořená
teoretikama a pro praxi se příliš nehodí.

Citace
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.
Opět směšuješ NULL a neuvedeno. Pro NULL to je zcela pravda. Ale v případě oprávnění, kde daná osoba může mít oprávnění pocházející z více zdrojů, je struktura, kde jsou existující oprávnění uložené, a ty co nejsou, prostě nejsou, naprosto normální a správná. A v takovém případě - pokud existuje i způsob jak určit "defaultní právo", tak má smysl i rozlišovat stav 0 = zakázáno.
Takže tady zmiňuješ sice správnou zásadu, ale na nesprávném místě.
A btw. i to explicitní NULL by v takové db struktuře mělo smysl, pokud by ta tabulka s právama obsahovala ještě něco dalšího a šlo by o denormalizaci: což je opět věc, kde se střetává teoretizování s realitou.
« Poslední změna: 06. 10. 2019, 17:09:54 od Logik »

 

reklama