Dotaz: Jaký typ sloupce pro true/false

[MArtin]

Ahoj, jaký zvolit typ sloupce v mysql aby se v sql dotazu v podmínce porovnávalo false/true

... WHERE check = true ...
... WHERE check = false ...

Ví někdo? Díky

Odpovědi

[Josef Kufner]

TINYINT(1), true = 1, false = 0.

[Kit]

Booleovské hodnoty v databázi považuji za chybu v návrhu. Proto nejlépe žádný, tedy takový sloupec v databázi nemít.

[cronin]

Booleovské hodnoty v databázi považuji za chybu v návrhu.

Dôvod?

[Kit]

Spíš by mě zajímal důvod, proč v databázi booleovské hodnoty mít. Velmi často jsou to redundantní údaje.

Kromě toho hledání podle boolean bude zpravidla provedeno jako full-scan, což není zrovna efektivní.

[Ivan]

Nejcasteji se "boolean" (aka CHAR(1)) poziva pro logicky delete. Misto toho aby se radka fyzicky smazala tak se jen oznaci jako smazana. Existuji ale i dalsi rozumne duvody.

K tomu aby se nepouzil full-table-scan staci pouzit index nad vice sloupci, popr. existuji i takove veci jako histogramy - takze se full-table-scan pouzije jen kdyz je to opravdu vyhodne.

[Kit]

Podle mne je mnohem výhodnější použít standardní DELETE. Ten záznam tam pak nepřekáží. Mám pak zvlášť živé a smazané záznamy - nemusím do každého SELECTu přidávat "WHERE deleted=false". Pokud potřebuji hledat v živých i smazaných záznamech, spojím ty dvě tabulky přes "UNION ALL".

[blondak]

tak to opravdu ne, co třeba relace, ....

[Kit]

Jaký je problém s relacemi?

[Šangala]

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…

[jekub]

odejde účetní porodit účetní. Z uživatelů smazat nejde - má na svědomí jakési vystavené doklady. char(1):=0

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

[jekub]

omlouvám se, zřejmě to bylo příliš stručné k pochopení. Ne, nepotřebuji poradit.

[xkucf03]

Co je s relacemi¹? 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}

[manasekp]

ja pouzivam hodnoty 0 a 1 pro oznaceni neceho co uz se "zpracovalo" tzn. webova stranka stazena, nejaky ucet otestovany atd. IMHO na tom neni nic spatneho. Ale jaky typ na to pouzit nevim, asi nejaky maly int stejne je to jedno.

[Kit]

V tomto případě je ta booleovská informace nadbytečná. Buď informace zpracována není (je tam null) nebo zpracována je a ve sloupci je výsledek.

[Filip Jirsák]

Co když je tím výsledkem několik řádků v jiné tabulce? Můžete pak samozřejmě používat v dotazu 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.

[Josef Kufner]

Docela často bývá žádoucí vědět, kdy se to stalo, takže se hodí timestamp nebo null. Počítané sloupce jsou v pohodě, o tom žádná.

[Kit]

V tom případě bývá často zajímavý ten počet. Místo primitivního true/false se například hodí počet nepřečtených zpráv, který se pak uživateli může zobrazit při každém reloadu stránky. Netuším, k čemu by se v daném případě hodil EXISTS.

[Filip Jirsák]

Tam žádný počet nebo něco podobného být nemusí. Třeba stáhnu podepsanou datovou zprávu z datových schránek, jako první ji uložím jako BLOB do archivu zpráv. Pak je tam nějaký asynchronní proces, který prochází nezpracované zprávy, rozparsuje je a uloží je do struktury několika tabulek. Z hlediska čistoty struktury tabulek by bylo nejsprávnější zjišťovat, zda je daná zpráva rozparsovaná, dotazem do té struktury tabulek. Z hlediska použitelnosti a výkonnosti je ale dobré mít tenhle příznak někde vyjádřený jako jeden atribut té tabulky zpráv.

Už jenom samotný fakt, že celé SQL je postavené na booleovské algebře (pro každou položku z prohledávané množiny se vyhodnotí, zda je podmínka 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.

[Kit]

Jak to souvisí s otázkou: Co když je tím výsledkem několik řádků v jiné tabulce?

Pokud je jako výsledek jeden řádek, tak tam buď je nebo není. Pokud je jich více, tak v nadřazené tabulce si udělám jejich čítač. Ani v jednom případě nepotřebuji boolean.

[Filip Jirsák]

Proč bych tam dával čítač, když ten údaj o počtu k ničemu nepotřebuju? S otázkou to souvisí tak, že je možné ji dál rozšířit na Co když je tím výsledkem několik řádků v jiných tabulkách? Přičemž některé ty řádky mohou být třeba sdíleny s dalšími záznamy (např. odesílatel datové zprávy bude mít v tabulce jenom jeden záznam, který bude provázán na všechny datové zprávy, které odeslal). To do toho čítače zapíšu celkový počet souvisejících záznamů, což je číslo, které je úplně k ničemu?

[Kit]

Pokud to číslo nepotřebuji, tak nebudu potřebovat ani takový sloupec, ani zmíněný boolean.

[Filip Jirsák]

Jak jsem psal výše, potřebuji vědět, které přijaté zprávy mám rozparsovat.

[Kit]

Jak jsem psal výše, nerozparsované zprávy nemají výsledek a proto se dají snadno detekovat i bez dalšího zbytečného sloupce typu boolean.

[Filip Jirsák]

Já ale nechci tu detekci psát pořád dokola. To, jestli je nebo není zpráva rozparsovaná, je její vlastnost, proto bych tuhle informaci rád našel jako atribut té zprávy. Třeba i proto, abych ho mohl použít ve složeném indexu. A teď nezáleží na tom, zda ten atribut bude někde fyzicky uložen, nebo se bude vždy dopočítávat.

Nebo jak by podle vás vypadaly indexy a dotaz, který mi vrátí nerozparsované zprávy seřazené podle data přijetí?

[Kit]

Nerozparsované zprávy jsou v jedné tabulce, po rozparsování se převedou do druhé tabulky. Jak prosté.

[Filip Jirsák]

Takže budu mít tři tabulky, jednu s ID (aby bylo kam odkazovat), a tabulku pro nerozparsované zprávy a druhou pro rozparsované zprávy, obě tabulky budou mít stejnou strukturu (to zavání špatným návrhem databáze)? Při parsování zprávy ten několikamegový BLOB z jedné tabulky smažu a do druhé zapíšu? To bude mít databázový stroj radost. Když budu potřebovat vypsat oba typy zprávy, budu muset použít SELECT UNION, který většinou databáze neumí moc optimalizovat (protože se většinou používá jen při špatně navržených strukturách databází).

Nebo abych ta data nepřesouval z jedné tabulky do druhé, budu mít data jen v jedné tabulce, a v druhé tabulce bude jenom seznam ID těch nerozparsovaných zpráv. Abych je mohl mít seřazené podle data přijetí, bude tam i počítaný sloupec odkazující na datum přijetí v té hlavní tabulce. Když budu chtít znát ten příznak zpracována/nezpracována, vždycky si tu druhou tabulku k té hlavní připojím.

Ano, existuje mnoho krkolomných způsobů, jak se vyhnout booleovské hodnotě. Ale proč to dělat, když ta modelovaná data prostě mají příznak typu ano/ne?

[Kit]

Implementaci fronty v SQL nepovažuji za vhodné řešení.

[Logik]

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

[Filip Jirsák]

V tomhle případě se ale nejedná jen o frontu. Ty podepsané datové zprávy jsou důkazní materiál a archivují se. Možná kdybyste implementoval jenom frontu, můžete zvolit jiné řešení. Ale pokud je o enterprise aplikaci, nemůžete si tam nastrkat dvacet různých technologií pro ukládání dat a u každé řešit vysokou dostupnost, zálohování a vzájemnou konzistenci dat.

[Kit]

Vypadá to, že pro určité speciální případy v enterprise aplikacích se boolean skutečně hodí.

[Josef Kufner]

Kdybych to dělal já, dám tam místo booleanu timestamp, abych věděl, kdy ke zpracování došlo. Nezpracované zprávy by měly NULL.

[manasekp]

vysledkem muze byt neco uplne jineho co se uklada do jine tabulky nebo se to vypise do problizece nebo do textoveho souboru (vsechny 3 pripady tady mam v ruznych skriptech vyuzite). Taky je v nekterych pripadech vhodna moznost vsechno "vynulovat" a zpracovat znovu.

[Josef Kufner]

Docela často je bool zneužit k rozlišení typu nebo stavu záznamu. V takových případech je vhodnější použít enum nebo referenci na entitu v jiné tabulce. Vhodnost booleanu se projeví v okamžiku, kdy je potřeba přidat třetí hodnotu.

[ffffffffffffffffffffffffffff]

boolean ma len 2 hodnoty - true a false, ak sa ma pridat 3 hodnota, tak to nie je boolean

[Kit]

Nepochopil jsi ironii. Pokud nějakou proměnnou uděláš boolean, po nějakém čase můžeš potřebovat třetí stav a musíš kvůli tomu předělat kus aplikace. Proto je obvykle lepší použít ENUM. Už kvůli tomu, že má mnohem vyšší vypovídací hodnotu než true/false.

[j]

Daleko lepsi je pouzit char nebo int ... protoze to bude stejne fungovat i jinde nez v mysql.

[Kit]

Je zbytečné se zabývat přenositelností mezi databázemi. Stejně se zpravidla musí struktura předělat, aby se využily schopnosti, které původní databáze neměla a ta nová je má.

[Šangala]

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…

Viz:
Three-valued logic
Boost.Tribool
C# bool? (Nullable)

[xkucf03]

Ty jsi nikdy nepotřeboval uložit jeden bit informace? Vždycky jich bylo víc?

[Kit]

Zpravidla je těch bitů informace víc a ten jeden bit byl zpravidla navíc. Velmi často se dá nahradit tím, že tam nějaká jiná informace je nebo není.

[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ě.

[Kit]

Ještě reakce na "nikdy": Protipólem je "alespoň jednou". Ano, výjimečně se mi stává, že potřebuji uložit jen jeden bit. Vždy si čtyřikrát rozmyslím, jestli to není způsobeno chybou v návrhu.

[Šangala]

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ý…

[blondak]

Dříve jsem BINARY(1) také používal, ale u něčeho, na co si za boha nevzpomenu, to dělalo problémy, takže moc nedoporučuji...

[Šangala]

Používám v MySQL snad všude

BINARY(1)

protože je to zkráceně

CHAR(1) CHARACTER SET binary

takže za boha nevím, kde by to mohlo dělat problém

[Josef Kufner]

Tyhle všelijaké obskurnosti způsobují, že klienti ty data zobrazují všelijak. Například v PHP funguje TINYINT(1) bezproblémově při přímém použití v podmínce. Tedy v kódu "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.

[OldFrog {Ondra Nemecek}]

Celá disuze mi přijde dost akademická. Pokud to vezmu prakticky, tak v Mysql lze uvést jednoduše typ BOOLEAN což je alias k TINYINT(1). Z toho je vidět, že Mysql interně používá TINYINT(1). Zápis pomocí BOOLEAN je ovšem srozumitelnější a řekl bych i přenositelnější na jiné DB. Pro hodoty mi pak z totožného důvodu přijde vhodnější zápis TRUE/FALSE, byť jde opět jen o aliasy k 1 a 0.

To co požaduje tazatel splňuje BOOLEAN dostatečně:

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.

[Martin Beránek]

Nechapu tu akademickou diskusi nad smysluplnosti booleanu. Prostě boolean je informace jako každá jiná a záleží na konkrétním případě, jestli je to opravdu výčet všech možností (i do budoucna) nebo ne.

Boolean používám na mazání a selecty pouštím nad materializovaným view který odfiltruje smazané záznamy... Výhody? podle mě hlavně fk z jiných tabulek

[Kit]

Nemohu za to, že se mnozí nedokáží smířit s tím, že se snažím booleovským proměnným vyhnout, jak to jen jde. Mohli mě ignorovat, ale místo toho neustále chtějí znát mé důvody a snaží se mi je vyvrátit. Co mám s nimi dělat? Asi ignorovat.

[lertimir]

Pokud to podáš takto, tak to podle mne znamená: "Nemám je rád a snažím se jim vyhnout, jak to jde." Tak to tě jistě budou ignorovat (nebo respektovat, že je nemáš rád.) Ale, když argumentaci stavíš jako logickou strukturu, která fakticky říká: "Je lepší stavět datový model tak, aby se v něm booleovské proměnné nevyskytovaly.", tak se nediv, že dostaneš spoustu otázek: Proč? a případně příkladů datových modelů, kde nepoužití booleovskych proměnných může znamenat značné komplikace v designu.

[Kit]

Však jsem to tak napsal. Zkus se podívat na můj první příspěvek. Zkus si přečíst i další mé příspěvky. Všechny prezentuji jako svůj názor.

[Logik]

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

[priman]

Pokud chceš maximální optimalizaci, tak můžeš použít nula znakový char s možností NULL, tím dosahneš největší optimalizace za cenu horší čitelnosti. Pokud chceš raději čitelnost, tak použij typ boolean, který je aliasem pro tinyint(1). Pokud to není něco na styl "show_on_homepage", kde je opravdu logicky jen true/false, ale bude to něco jako "where_show", kde chceš naprasit třeba true na top a false na bottom, tak použij enum/set, který bude názvem hodnoty situaci lépe popisovat a navíc ti umožní v budoucnu přidat další volbu.

[Josef Kufner]

Zrovna "show_on_homepage" je velmi brzy následováno požadavkem, aby to na homepage bylo jen v daném období.

[pocitujlasku]

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.

[Šangala]

Jestli MySQL CHAR(1) nebo MySQL TINYINT nebo v M$SQL 8× BIT v jedné tabulce je putna, okupuje to stejný prostor.