nicht angemeldet
Halihallo Ilja
Ein Vergleich ist möglich, das stimmt. Aber in dieser dreiwertigen
Logik gibt es nicht nur die Ergebnisse true|false, sondern auch
unknown (NULL).ein vergleich in einer WHERE klausel muss meiner meinung nach immer nur zwischen zwei zuständen unterscheiden, False oder TRUE oder wörtlich gesprochen nimm ich den datensatz oder nicht.
Genau, deshalb muss genau hier eine Konvention eingeführt werden,
die eben besagt, dass NULL als Auswertung der WHERE-Klausel als
FALSE *interpretiert* wird.
ein dbms muss halt eben eine entscheidung treffen, insofern ist mir der undefinierte zustand noch nicht ganz klar. ;-)
Nun, der NULL-"Wert" ist in der relationalen Datenbank-Welt (und
nicht nur da, es gibt ihn ja auch in einigen Programmiersprachen) ein
wichtiger Bestandteil. Aber wenn man sich erstmal entscheidet sowas
aufzunehmen, muss man das semantisch auch wirklich durchziehen. Die
Folge war, dass alle Operatoren und Funktionen einen wohldefinierten
Rückgabewert auf einen NULL-Operanden liefern mussten (String,
arithmetische, boolsche, ... Operatoren). Genauso musste z.B. auch
die WHERE-Klausel einen wohldefinierten Rückgabewert haben und dieser
ist per Definition (und wie du sagst) zwingend false oder true.
Entweder Tupel rein, oder raus aus der Ergebnisrelation [1]. Dieser
wohldefinierte Rückgabewert musste jedoch definiert werden, da man
aus einer dreiwertigen Logik nicht einfach auf ein zweiwertiges
Ergebnis (true|false) kommen kann. Dafür gibt es dann die
Konventionen, welche bei SQL besagt, dass wenn der Kontext eine
zweiwertige Logik erzwingt, NULL zu false wird; genausogut hätte man
sagen können, dass NULL zu true werden soll. Eine andere Konvention
besagt, dass NULL-Werte bei Agregatsfunktionen (ausser COUNT(*), der
ist ja nicht Attributwertbezogen) ignoriert werden. Wieder eine
andere Konvention besagt, dass NULL bei einem GROUP BY auch
als Wert angesehen wird. etc. etc.
Der undefinierte Wert hat also weitreichenden Einfluss auf eine
RDBMS. Und dies alles "nur", weil man ein unbekannter Wert auch
speichern möchte (sei es ein Preis eines Artikels, den man nicht
kennt, oder eine Referenz auf ein nicht vorhandenes Tupel (Foreign
Key) oder bei einem OUTER JOIN)...
Naja, der NULL-Wert ist wirklich ein spezieller Zeitgenosse, der
Umgang mit ihm birgt auch einige Gefahren...
[1] Ein "ich weiss nicht wohin mit dem Tupel" gibt es nicht :-)
Viele Grüsse
Philipp