Wie mit Feldern vergleichen, die (NULL) sind

[LeisureSuitLarry]

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

[LeisureSuitLarry]

Ja, es gibt mehrere Spalten die NULL sind.

sorry, Doppelpost

[p80286]

SQL-Code:

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. :gruebel: <-- 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:

Zitat von LeisureSuitLarry (Beitrag 1301425)

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:

Zitat von Dejan Vu (Beitrag 1301469)

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:

Delphi-Quellcode:

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

[Perlsau]

Ja und? Wenn du nochmal hinschaust, dann erkennst du vielleicht, daß das nichts mit dem Inhalt meines Postings zu tun hat.

Der Titel des Themas lautet übrigens: Mit Feldern verleichen, die NULL sind. Dazu wird hier gegensätzliches behauptet, so z.B.: "feld<>NULL ist ein valider Ausdruck und sollte keine Fehlermeldung ausgeben" im Gegensatz zu "

SQL-Code:

Feld<>Null

sollte eigentlich eine Fehlermeldung produzieren". Das kann man so pauschal nun aber nicht behaupten, weil nicht ganz klar ist, ob nun Delphi oder SQL gemeint ist, denn via SQL funktioniert zwar ein "feld<>NULL", in Delphi dagegen nicht.

Das war aber, wie gesagt, weder Thema noch Inhalt meines Postings, sondern diverse Behauptung meines Vorposters, die ich nicht mit meinen Vorstellungen vereinbaren konnte, was ich mit dem Hinweis, daß ich das nicht verstehe, zum Ausdruck gebracht habe.

Sonst alles klar? Gut geschlafen? Schmeckt der Kaffee? :-D

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1301473)

Zitat:

Zitat von Dejan Vu (Beitrag 1301469)

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 :lol:. 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:

Zitat von Perlsau (Beitrag 1301473)

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:

Delphi-Quellcode:

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.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1301481)

Zitat:

Zitat von Perlsau (Beitrag 1301473)

Zitat:

Zitat von Dejan Vu (Beitrag 1301469)

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 :lol:. 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.

Du meintest wohl eher: mindestens 1x nachgedacht. Das kann ich so nicht bestätigen, denn Nachdenken ist danach denken. Wenn ich eine Abfrage aller Records, deren Feld Adresse Null ist, benötige, muß ich nicht nachdenken, sondern lediglich Erfahrungswissen abrufen. So schnell kann ich gar nicht denken, wie dieses Wissen verfügbar ist. Das geht quasi automatisch und hat nichts mit Nachdenken zu tun. Nachdenken muß ich erst, wenn ich beim Coden stocke, weil ich erst überlegen – oder eben nachdenken – muß, wie ich das jetzt anstelle.

Ich hab z.B. eine Tabelle, da kriegt der Kunde regelmäßig neue Adressen rein, die sind unvollständig, mal fehlt die Straße, mal die Telefonnummer, mal die Postleitzahl usw. Um das zu ergänzen, kann er sich alle Kunden-Records anzeigen lassen, bei denen die Telefon-Nr. Null ist. Wo soll da ein Problem sein? Die Alternativen wären entweder im Grid alle Kunden-Datensätze durchzublättern, um optisch zu überprüfen, ob da irgendwo was fehlt – nicht sehr komfortabel. Oder die Datensätze zu sortieren und nach ganz oben oder ganz unten zu springen, um die Null-Einträge zu sehen – ein wenig komfortabler, aber nicht optimal.

Zitat:

Zitat von Dejan Vu (Beitrag 1301481)

Speziell bei parametrierten Abfragen wird das dann zu einer sehr unübersichtlichen Angelegenheit:

Wieso geht's jetzt plötzlich um parametrierte Abfragen? Doch nicht um deine Behauptung zu untermauern, oder? Ich finde, in der Pauschalität, in der du häufig argumentierst, übersiehst du meist, daß es noch viel mehr gibt, als auf deinen Teller paßt.

Zitat:

Zitat von Dejan Vu (Beitrag 1301481)

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)

Wieso geht's jetzt plötzlich um Reportfilter?

Zitat:

Zitat von Dejan Vu (Beitrag 1301481)

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

Darum geht's doch aber gar nicht ...

Zitat:

Zitat von Dejan Vu (Beitrag 1301481)

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

Und auch darum geht's in diesem Thread nicht.

Hat wenigstens der Kaffee geschmeckt?

[LeisureSuitLarry]

Danke für Eure Hilfe!

is NULL ist die Lösung.