Wie mit Feldern vergleichen, die (NULL) sind

[Perlsau]

Zitat von 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.

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 von Dejan Vu:

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 von Dejan Vu:

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 von Dejan Vu:

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 von Dejan Vu:

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.

[vagtler]

Zitat von LeisureSuitLarry:

[...] is NULL ist die Lösung.

Na, das ist ja eine Überraschung... http://www.delphipraxis.net/1301406-post3.html

[himitsu]

Joar, x IS NULL , x IS NOT NULL oder NOT (x IS NULL) schon vor langer Zeit genannt wurden,
in manchen DBMS auch die Abkürzungen x ISNULL oder x NOTNULL
und im Delphi-Code x.IsNull oder not x.IsNull .