Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: qwertz 28. 04. 2018, 08:56:57
-
Občas se při práci s SQL (eventuelně jinde) potýkám se školáckým problémem, kdy se snažím (nevědomky) provést nějakou operaci s hodnotou NULL. Než tuhle pitomou chybu vždycky odhalím, je to k naštvání jak podivně se to chová ;D
V praxi platí, že operace porovnání čehokoli s NULL nevrací "false" ale NULL, a operace 1 + NULL nevrací 1 ale NULL. Z jakého důvodu je to vlastně takto definováno? U matematické operace si lze asi představit, proč nechat výpočet spadnout do NULL, ale například u porovnání 1 = NULL fakt nechápu, proč nevrátit hodnotu "false".
-
já to beru tak, že NULL znamená chybějící hodnotu a pokud binární operaci chybí jeden operand tak chybí i výsledek
a pak SQL není Cčko :)
-
NULL není nula, prázdný string, ani false. Prostě nic.
Pokud chceš NULL transformovat na nějakou konkrétní hodnotu, použij COALESCE()
(https://i.stack.imgur.com/MxLUy.jpg)
-
primárně jde o rychlost, mít u každého porovnání ještě povinnou kontrolou na null je drahé a databáze šetří. Od toho jsou anotace u sloupců not null či default value, aby se právě tomuhle zabránilo.
Záleží na typu databáze, ale zpravidla NULL hodnoty neexistují v uložišti a nikam se neukládají. Jakékoliv větvení nebo podmínkové skoky jsou na úrovni CPU velice drahé a databáze je primárně určena pro rychlou práci s daty, to se od ní čeká a uživatelskou přívětivost ať si řeší programy nebo správný design modelu.
Za tohle chování jsem docela rád, nemám problém si tohle pohlídat a v kritických systémech ocením vyšší výkon za cenu lehce složitějšího vývoje.
-
Je to celkem logické: pokud chápeš NULL jako neznámou hodnotu, tak ji nelze porovnávat s jinou hodnotou, protože výsledkem by mohlo být true i false – to nevíš, tudíž výsledkem je opět neznámá hodnota tzn. NULL.
-
Null je cerna dira, napr. Jako /dev/null.
Cerna dira plus cokoliv je cerna dira.
-
NULL není nula, prázdný string, ani false. Prostě nic.
Pokud chceš NULL transformovat na nějakou konkrétní hodnotu, použij COALESCE()
COALESCE() znám a používám. Občas se prostě ve složitějším kódu zadaří, že nějaká funkce pro určitý případ vrátí NULL aniž bych to dopředu pohlídal a pak jsem naštvaný, protože se to chová divně ;D
Je to celkem logické: pokud chápeš NULL jako neznámou hodnotu, tak ji nelze porovnávat s jinou hodnotou, protože výsledkem by mohlo být true i false – to nevíš, tudíž výsledkem je opět neznámá hodnota tzn. NULL.
Já chápu NULL jako žádnou hodnotu, proto bych tak nějak čekal že třeba srovnání "text" = NULL vrátí false (něco se nerovná nic).
Zjevný smysl to dává spíš u matematických operací, přestože by se asi při troše dobré vůle dala zavést konvence, že "operátor NULL" (např. + NULL) se jednoduše ignoruje, takže 1+ NULL vrátí 1, 1 * NULL vrátí 1 apod. Ale chápu, že to má zřejmě výkonové důvody.
-
NULL není ani tak prázdná hodnota (jako třeba ve smyslu prázdného řetězce), jako spíš ne-hodnota, něco nedefinovaného. Podobně jako konstanta+$RANDOM je ve své podstatě taky $RANDOM. konstanta==$RANDOM? No, může a nemusí. Výsledek porovnání je taky "random".
-
Pokud by to mělo mít definovány výsledek, tak hrozí, že rozbijete logické axiomy. Jaký má být třeba výsledek 0 < NULL? JavaScript se to snaží definovat, ale má to fakt divné následky (0 < null ≡ false a 0 == null ≡ false, ale 0 <= null ≡ true).
-
Občas se při práci s SQL (eventuelně jinde) potýkám se školáckým problémem, kdy se snažím (nevědomky) provést nějakou operaci s hodnotou NULL. Než tuhle pitomou chybu vždycky odhalím, je to k naštvání jak podivně se to chová ;D
V praxi platí, že operace porovnání čehokoli s NULL nevrací "false" ale NULL, a operace 1 + NULL nevrací 1 ale NULL. Z jakého důvodu je to vlastně takto definováno? U matematické operace si lze asi představit, proč nechat výpočet spadnout do NULL, ale například u porovnání 1 = NULL fakt nechápu, proč nevrátit hodnotu "false".
Pokud si to dobře vybavuju, tak NULL v SQL odpovídá tomu, že v daném sloupci záznamu není žádná hodnota, prostě tam není nic.
(a proto NULL u stringu není prázdný řetězec, a ani to není 0 pro čísla)
A jak s tím cokoli porovnávat, nebo provádět matematické operace?
A proto je tam "speciální konstrukce" IS NULL / IS NOT NULL.
Další detaily už si moc nepamatuju, to je třeba si dostudovat.
(a každá konkrétní databáze může k normě přidat svoje špecifiká)
-
https://en.wikipedia.org/wiki/Null_(SQL) (https://en.wikipedia.org/wiki/Null_(SQL))
Ľudia, mohli by ste si aspoň prvý odstavec na wikipedii prečítať, než začnete mlžiť. NULL (v SQL) znamená "chýbajúcu informáciu a nepoužiteľnú informáciu". NULL (v SQL) nie je hodnota, ale stav. S optimalizáciou to nemá nič spoločné - v skutočnosti to komplikuje ako uloženie informácie, tak aj všetky operácie s ňou.
Za najväčšiu chybu pri návrhu jazyka SQL považujem, že použili na túto vec názov "NULL". Nepoznám jediného programátora, ktorý by si o to nenabil držku, pretože v ostatných "tradičných" programovacích jazykoch NULL znamená niečo iné.
-
Nepoznám jediného programátora, ktorý by si o to nenabil držku, pretože v ostatných "tradičných" programovacích jazykoch NULL znamená niečo iné.
Snad ve všech jazycích znamená null chybějící nebo nepoužitelnou informaci, a používání takové informace buď propaguje null (monády, optional) nebo rovnou selže (NullPointerException, SIGSEGV). Jen v pointerové aritmetice je null hodnota, a ta je prakticky vždy rovná nule.
-
V praxi platí, že operace porovnání čehokoli s NULL nevrací "false" ale NULL, a operace 1 + NULL nevrací 1 ale NULL. Z jakého důvodu je to vlastně takto definováno? U matematické operace si lze asi představit, proč nechat výpočet spadnout do NULL, ale například u porovnání 1 = NULL fakt nechápu, proč nevrátit hodnotu "false".
Já v tom nevidím žádný problém - libovolná operace vůči NULLu je NULL - nevidím žádný důvod, proč by toto pravidlo mělo mít výjimky (i když je samozřejmě má). Určitou logiku to dostane, až když člověk začne řešit predikáty IN, NOT IN.
NULL je relativně kontroverzní vlastnost SQL - teoreticky není potřeba (dost možná je to reakce na COBOL) a existují teoretické relační dotazovací jazyky bez NULL. Nicméně praktický smysl tam je - je to jedna hodnota, která je pro všechny typy mimo obor hodnot. Takže odpadá nutnost si definovat magické konstanty: "", -1, 0, 0000-00-00, ...
Z hlediska CPU, pokud budu mluvit o Postgresu, tak pro tabulky s vyššíma desítkama sloupců už může být test na NULL znát - tabulky, kde nejsou NULL hodnoty se načítají o fous rychleji (ale pozná se to třeba až u nějakého 70 - 80 sloupce). Ušetří se na uložišti - NULL je uložen jako 1bit bez ohledu na datový typ. Např. prázdný řetězec má minimálně 1byte, 0 v int má 4 bajty, ..
Jinak existuje několik funkcí a operátorů, které jsou vůči NULL imunní .. pro vás asi nejzajímavější by mohly být operátory IS DISTINCT FROM nebo IS NOT DISTINCT FROM, což je <> a = které zvládne NULL - v detailu https://stackoverflow.com/questions/27134368/is-is-distinct-from-a-real-mysql-operator
-
NULL je relativně kontroverzní vlastnost SQL - teoreticky není potřeba (dost možná je to reakce na COBOL) a existují teoretické relační dotazovací jazyky bez NULL. Nicméně praktický smysl tam je - je to jedna hodnota, která je pro všechny typy mimo obor hodnot. Takže odpadá nutnost si definovat magické konstanty: "", -1, 0, 0000-00-00, ...
Ono lidi občas na to NULL v SQL nadávají, ale když se člověk zamyslí, jak by pak vypadal datový model běžné aplikace, tak by to asi nikdo používat nechtěl. Čisté řešení by bylo přesunout nepovinné atributy do samostatných tabulek a provázat je přes cizí klíče. Pak by si člověk užil opravdu hodně JOINů… A prasácké řešení je zahnojit model a kód těmi magickými konstantami – a pak se divit, proč se to chová „podivně“ a vypadávají z toho nečekané výsledky – protože se třeba někde přičetla ta -1 nebo jiná speciální hodnota. To je ještě větší peklo než to první řešení.
Ale pokud někdo touží po SQL bez NULL, může ho klidně mít – stačí si u všech sloupců nastavit NOT NULL a tuto hodnotu jednoduše nepoužívat.
-
Ale pokud někdo touží po SQL bez NULL, může ho klidně mít – stačí si u všech sloupců nastavit NOT NULL a tuto hodnotu jednoduše nepoužívat.
až na to že hodnotu NULL může vrátit některá built-in funkce.
-
Ale pokud někdo touží po SQL bez NULL, může ho klidně mít – stačí si u všech sloupců nastavit NOT NULL a tuto hodnotu jednoduše nepoužívat.
až na to že hodnotu NULL může vrátit některá built-in funkce.
Mluvím za Postgres - základní vestavěné funkce typicky vrací NULL pouze pokud je některý parametr NULL. Jinak při chybě vyhodí výjimku. MySQL se bude chovat jinak, tak jsou víc fault tolerant a právě více používají NULLy. U Pg vím, že snad asi jen funkce pro práci s poli mohou vracet NULL - pokud se sáhne mimo pole, a pokud se ptám na rozměry prázdného pole (přičemž to poslední chování se spíš bere jako chyba, kterou nejde opravit z důvodu porušení kompatibility (a je tam alternativní funkce, která se chová jinak)).
-
Mluvím za Postgres - základní vestavěné funkce typicky vrací NULL pouze pokud je některý parametr NULL. Jinak při chybě vyhodí výjimku.
Těch scénářů bude víc. Např. substring(regex) vrátí NULL, když nenajde definovaný pattern. Pak už jen stačí výsledek porovnat s hledaným stringem, výsledný boolean převést na integer a něco s ním počítat a výsledný NULL vyleze místě, kde ho na první pohled nečekáte ;D
Prostě je třeba automaticky pořád myslet na to, které funkce vrací NULL a hned to ošetřit např. COALESCE().
-
Mluvím za Postgres - základní vestavěné funkce typicky vrací NULL pouze pokud je některý parametr NULL. Jinak při chybě vyhodí výjimku.
Těch scénářů bude víc. Např. substring(regex) vrátí NULL, když nenajde definovaný pattern. Pak už jen stačí výsledek porovnat s hledaným stringem, výsledný boolean převést na integer a něco s ním počítat a výsledný NULL vyleze místě, kde ho na první pohled nečekáte ;D
Prostě je třeba automaticky pořád myslet na to, které funkce vrací NULL a hned to ošetřit např. COALESCE().
Ju, to tam je - důvod netuším - asi chtěli tvůrci rozlišit mezi prázdným řetězcem a žádným řetězcem - nebo je to funkce, která přišla do standardu z Oracle, a tam se mezi NULLem a prázdným řetězcem nerozlišuje. Nicméně stále tohle chování je opravdu velkou výjimkou - což možná působí víc komplikací než kdyby bylo obvyklé. SQL mám rád a beru ho za jeden z nejlepších IT nástrojů, ale ANSI SQL rozhodně není do mrtě konzistentní.
-
Mluvím za Postgres - základní vestavěné funkce typicky vrací NULL pouze pokud je některý parametr NULL. Jinak při chybě vyhodí výjimku.
Těch scénářů bude víc. Např. substring(regex) vrátí NULL, když nenajde definovaný pattern. Pak už jen stačí výsledek porovnat s hledaným stringem, výsledný boolean převést na integer a něco s ním počítat a výsledný NULL vyleze místě, kde ho na první pohled nečekáte ;D
Prostě je třeba automaticky pořád myslet na to, které funkce vrací NULL a hned to ošetřit např. COALESCE().
NULL je také informací. COALESCE() tuto informaci nahrazuje jinou informací, která nemusí být vždy vhodná. Dost často se setkávám s tím, že někdo do databáze místo času NULL narve nějakou nesmyslnou hodnotu "0000-00-..." To je na zabití.
-
Mluvím za Postgres - základní vestavěné funkce typicky vrací NULL pouze pokud je některý parametr NULL. Jinak při chybě vyhodí výjimku.
Těch scénářů bude víc. Např. substring(regex) vrátí NULL, když nenajde definovaný pattern. Pak už jen stačí výsledek porovnat s hledaným stringem, výsledný boolean převést na integer a něco s ním počítat a výsledný NULL vyleze místě, kde ho na první pohled nečekáte ;D
Prostě je třeba automaticky pořád myslet na to, které funkce vrací NULL a hned to ošetřit např. COALESCE().
NULL je také informací. COALESCE() tuto informaci nahrazuje jinou informací, která nemusí být vždy vhodná. Dost často se setkávám s tím, že někdo do databáze místo času NULL narve nějakou nesmyslnou hodnotu "0000-00-..." To je na zabití.
Nebo 2999-12-31 23:59:59 jako „nekonečno“ – jasně, ten software v tom roce už existovat nebude, ale stejně…
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná? Tzn. někdy známe jen datum ale ne čas. Špatné řešení je dát čas 00:00:00, protože pak nejde rozlišit zda se daná věc stala a) na začátku daného dne nebo b) kdykoli během dne (nevíme, kdy). Asi nezbývá, než to rozdělit do dvou sloupců/parametrů a čas mít někdy NULL, že?
-
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná? Tzn. někdy známe jen datum ale ne čas. Špatné řešení je dát čas 00:00:00, protože pak nejde rozlišit zda se daná věc stala a) na začátku daného dne nebo b) kdykoli během dne (nevíme, kdy). Asi nezbývá, než to rozdělit do dvou sloupců/parametrů a čas mít někdy NULL, že?
Rozdělit to do dvou sloupců, při porovnání budete potřebovat dva údaje (porovnání data, porovnání času), jinak nebude fungovat porovnání data bez času s datem s časem ve stejném dni (stejný den = TRUE, stejný čas = NULL).
-
NULL je také informací. COALESCE() tuto informaci nahrazuje jinou informací, která nemusí být vždy vhodná. Dost často se setkávám s tím, že někdo do databáze místo času NULL narve nějakou nesmyslnou hodnotu "0000-00-..." To je na zabití.
Ano, to je kolosální pitomost. Nicméně zda pole může nebo nemůže obsahovat NULL je zřejmé na první pohled (definice sloupce NOT NULL). Tam se to dá odchytit celkem snadno. Na rozdíl od funkce, kde se hodnota NULL "nečekaně" objeví na výstupu. Jasně, každá funkce má definováno, zda vrací NULL a za jakých podmínek, ale to už je třeba aktivné hlídat.
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná?
čisté řešení je to rozdělit a když chybí nahradit NULL.
-
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná? Tzn. někdy známe jen datum ale ne čas. Špatné řešení je dát čas 00:00:00, protože pak nejde rozlišit zda se daná věc stala a) na začátku daného dne nebo b) kdykoli během dne (nevíme, kdy). Asi nezbývá, než to rozdělit do dvou sloupců/parametrů a čas mít někdy NULL, že?
Nabízí se ukládat takový časový údaj ve stringu:
"2018-04" - někdy v dubnu 2018
"2018-04-29 13" - dnes ve mezi 13. a 14. hodinou
-
NULL je také informací. COALESCE() tuto informaci nahrazuje jinou informací, která nemusí být vždy vhodná. Dost často se setkávám s tím, že někdo do databáze místo času NULL narve nějakou nesmyslnou hodnotu "0000-00-..." To je na zabití.
Ano, to je kolosální pitomost. Nicméně zda pole může nebo nemůže obsahovat NULL je zřejmé na první pohled (definice sloupce NOT NULL). Tam se to dá odchytit celkem snadno. Na rozdíl od funkce, kde se hodnota NULL "nečekaně" objeví na výstupu. Jasně, každá funkce má definováno, zda vrací NULL a za jakých podmínek, ale to už je třeba aktivné hlídat.
Velmi často se chybuje v tom, že se NOT NULL definuje automaticky v každém sloupci a pak se pracně obchází situace, kdy tam žádný časový údaj nemá být uložen (schváleno dne apod.) Základem je naučit se s hodnotou NULL pracovat a nechat ji tam, kde má být.
-
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná? Tzn. někdy známe jen datum ale ne čas. Špatné řešení je dát čas 00:00:00, protože pak nejde rozlišit zda se daná věc stala a) na začátku daného dne nebo b) kdykoli během dne (nevíme, kdy). Asi nezbývá, než to rozdělit do dvou sloupců/parametrů a čas mít někdy NULL, že?
Nabízí se ukládat takový časový údaj ve stringu:
"2018-04" - někdy v dubnu 2018
"2018-04-29 13" - dnes ve mezi 13. a 14. hodinou
Tam bude problém, kam dát časovou zónu a obecně se mi nelíbí používání jiného datového typu… stejně by to pak bylo potřeba obalit vlastními funkcemi, aby se s tím dalo pracovat.
Zajímavější by byl datový typ, který by kromě samotné informace obsahoval i její přesnost. Nebo to dát do dvou sloupců (případně do jednoho typu „interval“) a ten první by značil dolní mez a ten druhý horní. A výsledkem porovnání by pak byly čtyři možné stavy:
- událost A nastala před událostí B
- událost B nastala před událostí A
- události A a B nastaly v přesně stejný okamžik
- událost A a B nastaly ve stejný den (měsíc, rok, minutu…), ale nedokážeme přesněji říct, zda bylo dřív A nebo B
Resp. jsou to spíš tři stavy, protože ta třetí možnost je speciální případ té čtvrté, jelikož i ten „přesně stejný okamžik“ má nějakou granularitu (měříme na minuty, vteřiny, ms, ns… ale v rámci dané jednotky už to nedokážeme přesněji rozlišit).
Pokud půjdeme ještě o krok dál, mohli bychom evidovat pravděpodobnost, s jakou je daná informace pravdivá. Na tohle jsem se ptal kdysi ve škole, ale nikdo mi na to nedokázal odpovědět (v kontextu SQL a relačních databází). Např. budeme mít část hodnot přesně změřených, tak u nich dáme pravděpodobnost 100 % a pak máme část hodnot, které jsme tak trochu odhadovali, měřili nepřesným nástrojem atd. tak u nich dáme pravděpodobnost třeba jen 80 %. Když pak budeme dělat nějaké agregace, může nám z toho vypadnout i pravděpodobnost celkového výsledku, optimistické a pesimistické odhady…
-
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná? Tzn. někdy známe jen datum ale ne čas. Špatné řešení je dát čas 00:00:00, protože pak nejde rozlišit zda se daná věc stala a) na začátku daného dne nebo b) kdykoli během dne (nevíme, kdy). Asi nezbývá, než to rozdělit do dvou sloupců/parametrů a čas mít někdy NULL, že?
Nabízí se ukládat takový časový údaj ve stringu:
"2018-04" - někdy v dubnu 2018
"2018-04-29 13" - dnes ve mezi 13. a 14. hodinou
Tam bude problém, kam dát časovou zónu a obecně se mi nelíbí používání jiného datového typu… stejně by to pak bylo potřeba obalit vlastními funkcemi, aby se s tím dalo pracovat.
Zajímavější by byl datový typ, který by kromě samotné informace obsahoval i její přesnost. Nebo to dát do dvou sloupců (případně do jednoho typu „interval“) a ten první by značil dolní mez a ten druhý horní. A výsledkem porovnání by pak byly čtyři možné stavy:
- událost A nastala před událostí B
- událost B nastala před událostí A
- události A a B nastaly v přesně stejný okamžik
- událost A a B nastaly ve stejný den (měsíc, rok, minutu…), ale nedokážeme přesněji říct, zda bylo dřív A nebo B
Resp. jsou to spíš tři stavy, protože ta třetí možnost je speciální případ té čtvrté, jelikož i ten „přesně stejný okamžik“ má nějakou granularitu (měříme na minuty, vteřiny, ms, ns… ale v rámci dané jednotky už to nedokážeme přesněji rozlišit).
Pokud půjdeme ještě o krok dál, mohli bychom evidovat pravděpodobnost, s jakou je daná informace pravdivá. Na tohle jsem se ptal kdysi ve škole, ale nikdo mi na to nedokázal odpovědět (v kontextu SQL a relačních databází). Např. budeme mít část hodnot přesně změřených, tak u nich dáme pravděpodobnost 100 % a pak máme část hodnot, které jsme tak trochu odhadovali, měřili nepřesným nástrojem atd. tak u nich dáme pravděpodobnost třeba jen 80 %. Když pak budeme dělat nějaké agregace, může nám z toho vypadnout i pravděpodobnost celkového výsledku, optimistické a pesimistické odhady…
To už se dostáváte do fuzzy aritmetiky - s klasickými typy by to šlo dost ztuha - ale asi by nebyl problém napsat si vlastní typy, kde by se bokem ukládala pravděpodobnost (případně přesnost). Viděl jsem pár studií, které se o něco takového pokoušely, ale asi to neopustilo akademickou půdu. Případně se to řeší v aplikaci.
-
BTW: máte někdo nápad, jak zaznamenávat datum a čas s tím, že časová složka nemusí být vždy přítomná? Tzn. někdy známe jen datum ale ne čas. Špatné řešení je dát čas 00:00:00, protože pak nejde rozlišit zda se daná věc stala a) na začátku daného dne nebo b) kdykoli během dne (nevíme, kdy). Asi nezbývá, než to rozdělit do dvou sloupců/parametrů a čas mít někdy NULL, že?
Nabízí se ukládat takový časový údaj ve stringu:
"2018-04" - někdy v dubnu 2018
"2018-04-29 13" - dnes ve mezi 13. a 14. hodinou
V PG je možné použít date range nebo timestamp range. Tudíž string není nutný - a můžete vyhledávat kolize intervalů, případně jejich sjednocení, ..
-
Pokud půjdeme ještě o krok dál, mohli bychom evidovat pravděpodobnost, s jakou je daná informace pravdivá. Na tohle jsem se ptal kdysi ve škole, ale nikdo mi na to nedokázal odpovědět (v kontextu SQL a relačních databází). Např. budeme mít část hodnot přesně změřených, tak u nich dáme pravděpodobnost 100 % a pak máme část hodnot, které jsme tak trochu odhadovali, měřili nepřesným nástrojem atd. tak u nich dáme pravděpodobnost třeba jen 80 %. Když pak budeme dělat nějaké agregace, může nám z toho vypadnout i pravděpodobnost celkového výsledku, optimistické a pesimistické odhady…
To už se dostáváte do fuzzy aritmetiky - s klasickými typy by to šlo dost ztuha - ale asi by nebyl problém napsat si vlastní typy, kde by se bokem ukládala pravděpodobnost (případně přesnost).
To, co chce provadet Franta <xkucf03/>, neni fuzzy aritmetika (coz je IMHO teda docela pochybna aplikace fuzzy logiky), ale pouze intervalova aritmetika, ktera by bez vetsich problemu mela jit uchopit zavedenim vlastniho dvouprvkoveho kompozitniho typu a deklaraci vhodnych operatoru a agregacnich funkci. Coz vse Postgres umi.
Vetsi problem nez uchopit to technicky, bude pro vetsinu lidi problem uchopit to koncepcne. V podstate se jedna o zpracovani nejistoty (uncertainty) v datech. Avsak moznych typu nejistoty v datech je hned nekolik druhu. Jenom v predchozich prispevcich byly zmineny tri, a aby se databaze chovaly spravne a data davala smysl, je potreba spravne volit typ nejistoty a prace s nim.
Jedna vec je napriklad nejistota zpusobena merenim, tj. namerena hodnota +/- presnost meridla. V tomto pripade nejde rict, ze hodnota je 10 cm s pravdepodobnosti 80% a 10.2 cm s pravdepodobnosti 20%.
Vedle toho se da uvazovat o pravdepodponosti nejakeho jevu, napr. atribut y ma hodnotu Q s pravdepodobnosti 40%; nebo radek [x,y,z] se vyskytuje v tabulce s pravdepodobnosti 30%. To umoznuje resit ulohy typu, kniha se nachazi v knihovne na 90%, nebo zamestnanec se nachazi v kancelari XY s pravdepodobnosti 80% a v kancelari YZ s pravdepodobnosti 10%. Timto smerem se vydavaji pravdepodobnosti databaze.
A aby toho nebylo dost, muzeme data v rel. databazi uchopit jeste s pomoci fuzzy logiky. To v tom pripade znamena, ze zacneme uvazovat stupne pravdivosti jednotlivych vyroku. Napr. vyrok: "logo postgresql je modre" ma stupen pravdivosti 1; "logo mysql je modre" muze mit stupen pravdivosti 0.6; pricemz "logo mysql je oranzove" muze mit treba stupen pravdivosti 0.5 a "logo mysql je ruzove" ma stupen pravdivosti 0 (nepravdivy vyrok)