Wie mit Feldern vergleichen, die (NULL) sind

[LeisureSuitLarry]

ich kenne 'coalesce' gar nicht. Wenn es die einzige Klausel ist funktioniert es.
Wenn es aber mehrere gibt, findet er wieder nichts, also z. B.

update tabelle
set X=Y
where (coalesce(x, '') <> '') and (coalesce(z, '') <> '')

z ist eine weiter Spalte, die auch NULL sein kann.

[jobo]

Zitat von LeisureSuitLarry:

where (coalesce(x, '') <> '') and (coalesce(z, '') <> '')

In dem Fall müssten ja beide Spalten gemeinsam Null sein. Gibt es solche Datensätze?

[LeisureSuitLarry]

ja, es gibt mehrere Spalten die NULL sein können.

[LeisureSuitLarry]

Ja, es gibt mehrere Spalten die NULL sind.

sorry, Doppelpost

[p80286]

Feld<>Null sollte eigentlich eine Fehlermeldung produzieren
Wenn Du ein Feld auf Null oder einen Inhalt prüfen willst dann so:

SQL-Code:

..
and (Feld=irgendwas or Feld is null)
...

Gruß
K-H

[Dejan Vu]

feld<>NULL ist ein valider Ausdruck und sollte keine Fehlermeldung ausgeben. <-- edit.

Nichts ist == NULL. Ebenso ist nichts <> NULL. NULL ist nicht vergleichbar. Daher gibt es IS NULL und IS NOT NULL.

Code:

Update table set x=y where x is null

Im Beispiel von p80286 sieht man, wie komplex die Arbeit mit NULL Werten werden kann. Daher sollte man davon Abstand nehmen, bzw. dreimal überlegen, ob NULL als abzufragendes Datum wirklich notwendig ist.

[Perlsau]

Zitat von LeisureSuitLarry:

Ja, es gibt mehrere Spalten die NULL sind.

Spalten können nicht NULL sein, sondern einzelne Felder einzelner Records. Spalten bestehen aus demselben Feld aller in dieser Tabelle gespeicherten Records. In einer Spalte können manche Einträge NULL sein und andere wiederum nicht. Die Spalte bzw. das Feld wird in der Tabellendefinition deklariert und kann wie gesagt nicht NULL sein, das ist überhaupt keine Eigenschaft einer Spalte.

Zitat von Dejan Vu:

Im Beispiel von p80286 sieht man, wie komplex die Arbeit mit NULL Werten werden kann. Daher sollte man davon Abstand nehmen, bzw. dreimal überlegen, ob NULL als abzufragendes Datum wirklich notwendig ist.

Das verstehe ich jetzt nicht: Wie sollte man dann ohne den Test auf Null herausfinden, ob ein Feld einen Eintrag enthält? Jetzt erzählst du mir sicher gleich, das käme in der Praxis nicht vor, oder?

Also ich muß da nur einmal überlegen, ob ich z.B. eine Selection "where Feld is Null" anfordere oder nicht. Oder besser, ich muß eigentlich gar nicht überlegen, denn da gibt's nicht wirklich was zu überlegen, wenn man die Records einer Tabelle, deren Feld X Null ist, benötigt, z.B.:

Code:

select * from PERSONEN where PERS_ADRES is null

Oder in Delphi:

Qset_Personen.Filter := 'PERS_ADRES is null'; Was also sollte man da groß überlegen? Und was soll am Beispiel von p80286 komplex sein?

[hstreicher]

er testet auf ungleich null


update Tabelle set X=Y where x<>NULL


richtig wäre also IS NOT NULL

update Tabelle set X=Y where x is not null

[Dejan Vu]

Zitat von Perlsau:

Zitat von Dejan Vu:

Im Beispiel von p80286 sieht man, wie komplex die Arbeit mit NULL Werten werden kann. Daher sollte man davon Abstand nehmen, bzw. dreimal überlegen, ob NULL als abzufragendes Datum wirklich notwendig ist.

Das verstehe ich jetzt nicht: Wie sollte man dann ohne den Test auf Null herausfinden, ob ein Feld einen Eintrag enthält? Jetzt erzählst du mir sicher gleich, das käme in der Praxis nicht vor, oder?

Falsch, denn Du hast maximal 1x nachgedacht . Wenn man in seiner Logik die Abfrage auf NULL benötigt, sollte man hinterfragen, was man damit eigentlich beabsichtigt und dies dann ggf anders formulieren. Speziell bei parametrierten Abfragen wird das dann zu einer sehr unübersichtlichen Angelegenheit:

Code:

select * from Tabelle
  Where (Name is null or Name = :Name)
     or (Foobar is Null or Foobar = :Foobar)
   ...

Natürlich könnte man COALESCE oder ISNULL nehmen, aber da geht dann der Vorteil eines Index schnell flöten.
Bei einer Abfrage auf 'Daten vorhanden/nicht vorhanden' ist das natürlich vollkommen ok, aber wenn die Spalte in Reportfiltern vorkommt, ist das dann wieder blöd, wg. (siehe oben).

Zitat von Perlsau:

Was also sollte man da groß überlegen? Und was soll am Beispiel von p80286 komplex sein?

Die Notwendigkeit, einerseits auf den Wert und andererseits auf NULL prüfen zu müssen.

Etwas OT: Stell dir vor, Deine Tabelle enthält eine Spalte 'A varchar(10) NULL'. Du schreibst nun einen Report und möchtest das Ergebnis filtern, so etwa:
select * from Tabelle where A=:A Nun kann die Spalte A NULL-Werte enthalte, weil, ist ja nicht komplex. Nun willst Du auch darauf abfragen können. Wie machst Du das jetzt? Dein Parameter 'A' kann ja schlecht 'NULL' enthalten, also?

Code:

select * from Tabelle 
where (:A is not null and A=:A)
   or (:A is null and A is null)

Stimmt das überhaupt so? (Query Optimizer lieben deartige Konstrukte übrigens). Wie Du siehst, ist das spätestens jetzt komplex, vor allen Dingen dann, wenn sich das über alle Spalten hinzieht. Also lieber: Finger weg (oder keine Reports mit NULL-Filtermöglichkeit).

Wenn man einen Report benötigt, der auch alle z.B. unausgefüllten TelefonNr-Spalten zeigt, dann lieber explizit als separaten Report oder man deklariert die Telefon-Spalte als NOT NULL und dann hat der leere String die Bedeutung: 'unausgefüllt'.

Aber klar: Manchmal geht es nicht anders und dann ist man auch wieder froh über NULL (LEFT JOIN z.B.)

PS: Das mit dem Kaffee war ein gutes Stichwort.