Portál AbcLinuxu, 13. května 2025 00:52
... WHERE check = true ... ... WHERE check = false ...Ví někdo? Díky
Booleovské hodnoty v databázi považuji za chybu v návrhu.Dôvod?
Blbě se přemísťují (fyzicky mažou) číselníkové záznamy, je třeba komplexní update, který může být nežádoucí, takže se záznam jen oflaguje, bo to referenční integritu nerozbije…
Jestlu tomu budeme říkat mazání nebo třeba řízení accessibility je putna…
27.5.2014 17:39
xkucf03 | skóre: 49
| blog: xkucf03
V takovém případě už nejde z logiky věci o smazání, ale o změnu stavu – ten člověk nezmizel, nepřestal existovat, DELETE (ani ten „logický“) nedává smysl – pouze se změnil stav (nějaký příznak) a ten člověk už u nás nepracuje. A třeba se zase jednou vrátí. Rozhodně bys tam neměl mít sloupec smazáno, ale spíš zaměstnanec (boolean) nebo datumukončenípracovního_poměru (datum a čas) případně mít nějakou další tabulku, ve které budeš sledovat, v jakých obdobích u tebe pracoval. Případně se tohle dá řešit přes role – v tabulce uživatelů bude pořád, ale odebereš mu všechna práva/role (včetně „aktivní zaměstnanci“).
27.5.2014 17:32
xkucf03 | skóre: 49
| blog: xkucf03
Co je s relacemi1? Nebo ty myslíš vazby 1:N, M:N?
Hodnoty cizích klíčů můžeš nastavit na NULL, nebo smazat i navázané záznamy, podle toho, co dává smysl.
[1] tabulkami
15.5.2014 00:57
EXISTS, ale možná ten údaj nechcete počítat pořád dokola, možná ho dokonce potřebujete použít v indexu, takže použijete počítaný sloupec. A v tom počítaném sloupci bude výsledek toho EXISTS.
WHERE splněna nebo nesplněna), svědčí o tom, že v používaných modelech existují atributy, které mohou nabývat logických hodnot ano/ne.
aneb jak neuznat, že tvrdím s odpuštěním hovadinu.
V čem bys to tedy implementoval, když bys měl zároveň požadavek na zajištění konzistence dat tak, aby to byla levně udržovatelná technologie (a tedy bys moh levně vývojáře "vyměnit" za jiný ucho co to bude za pár korun udržovat a dál vyvíjet)?
-------
Jinak k původnímu offtopic tématu. Enum a bool jsou dvě různé věci a hodí se na různé věci. Bool je odpověď na otázku zjišťovací, enum na otázku doplňovací. Pokud údaj v databázi je opravdu odpověď na otázku zjišťovací, není důvod ho nepoužít a použít enum je naopak špatné.
To, že se dosti často dělá v návrhu chyba a odpověď na otázku doplňovací se dělá pomocí série odpovědí na zjišťovací otázky (tzn. místo jakou má barvu? je v db je červený? je modrý? je zelený?) na věci nic nemění. Ono někdy se naopak dělá i opačná chyba, např. místo otázek: Je student? Je důchodce? se dá jedna otázka Co je? a když se pak změní legislativa a objeví se student důchodce, tak se může celá aplikace přepsat.
PS: To, že ve výše zmíněném případu je velmi na zvážení, jestli neudělat child tabulku ČlověkJeNěco, kam sypat příznaky, je pravda. Ovšem v případě, kdy se množina těchto statusů mění jen velmi zřídka, to bývá často overkill.
Nebuď si tak jistý, to dogma nemusí být tak pevné, jak by se na první pohled zdálo
Dokonce si myslím, že právě při programování, je daleko častější a potřebná Three-valued logic. Tedy stavy true/false/unknow (nebo true/false/not-true-and-not-false) jsou daleko běžnější než jen prosté true/false, a v SQL je to de-facto běžně používaný přístup maskující se pod NULL…
27.5.2014 17:30
xkucf03 | skóre: 49
| blog: xkucf03
Ty jsi nikdy nepotřeboval uložit jeden bit informace? Vždycky jich bylo víc?
27.5.2014 18:31
xkucf03 | skóre: 49
| blog: xkucf03
Velmi často se dá nahradit tím, že tam nějaká jiná informace je nebo není.
S tím souhlasím – např. tam může být čas, kdy něco přestalo platit nebo bylo dokončeno (třeba doručení objednávky, dokončení studia) nebo to jde převést na další tabulku (historie stavů). Ale je otázka, jestli tyhle dodatečné informace chceš sledovat – někdy je nepotřebuješ nebo je to dokonce nežádoucí (ohrožovalo soukromí nebo zabíralo zbytečné místo na disku), tak se boolean perfektně hodí. Rozhodně bych z toho nedělal nějaké dogma a neříkal, že boolean v DB je špatně.
CHAR(1) | BINARY(1) popřípadě ENUM, stejně dříve nepozději potřebuješ minimálně three-valued typ.
Často volím variantu BINARY(1), protože jsem líný…
BINARY(1)protože je to zkráceně
CHAR(1) CHARACTER SET binarytakže za boha nevím, kde by to mohlo dělat problém
if ($row['col']) { ... }" zafunguje, jak je očekáváno. Viděl jsem ale používat i ENUM('Y', 'N'), kde pak obojí znamená true.
CREATE TABLE t ( id int not null primary key auto_increment, value boolean ); INSERT INTO t (value) VALUES (FALSE),(TRUE),(NULL); SELECT * FROM t WHERE value = TRUE;Ohledně debaty zda je vůbec vhodné používat boolean - to je přece třeba zvážit vždy podle situace. Je na místě upozornit, že použití např. enum nebo set místo booleanu může být flexibilnější, ale podrobnější rozbor by měl smysl jedině v případě, že bychom znali celé zadání tazatele.
"Booleovské hodnoty v databázi považuji za chybu v návrhu. Proto nejlépe žádný, tedy takový sloupec v databázi nemít."Tak tvrdíš, že citované pravidlo má generální platnost, nebo ne? Pokud ne a je to jen nějaké pravidlo, kterého se z nevímjakého důvodu držíš, proč ho sem píšeš? Z toho je vidět, že normální člověk pochopí, že tomu tvrzení generální platnost dáváš. Oak se ovšem nediv, že se Ti ostatní snaží (a imho úspěšně) to pravidlo vyvrátit. Protože se snaží tazateli poradit - pokud tedy dá tazateli někdo radu špatnou, tak se tu radu snaží korigovat. Akorát jsou slušní a místo aby rovnou napsali, že se mýlíš, tak nejdřív chtějí vědět důvody, proč to tvrdíš. Takže ano, mohli Tě ignorovat, ale tím by byl uveden tazatel v omyl. Proto bylo správné, když na Tebe reagovali. Pokud si furt připadáš "nevině", tak pokládal bys za chybu ostatních, kdyby na radu "jak nainstalovat mysql" někdo reagoval, že on to dělá příkazem "rm / -rf" a Ti ostatní na to reagovali, že nemá pravdu? Nebo by to byla chyba toho člověka, co by tam tu blbinu napsal, byť jen "jako svůj názor"?
ja v mssql pouzivam bit.
True/false ma vyznam aj v pripade, mam vo front-end formular s checkboxmi. ako ulozim informaciu o tom, co je zvolene, alebo nie? tu informaciu potrebujem uchovat, lebo ju vyuzivam v dalsich storkach. int mi pride plytvanie, char(1) tiez nie je vhodny...
pripadne dost vyuzivam na identifikaciu, ci je zvoleny zaznam aktivny, alebo nie Active 0/1 - napr. uzivatel.
MySQL CHAR(1) nebo MySQL TINYINT nebo v M$SQL 8× BIT v jedné tabulce je putna, okupuje to stejný prostor.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.