SQL int NULL Wert

[chablife]

Hallo allerseits,

ich hätte da mal eine Frage zu SQL, für dich ich auf Google noch keine Antwort gefunden habe.

Es wird im Management Studio von Microsoft entwickelt.

Es gibt eine Spalte mit bigint Werten. Es kann sein, dass die Spalte allerdings keinen Wert hat. Und wenn es keinen Wert hat, ist dort der Wert NULL. Das darf eben nicht sein, es soll leer sein.

Ich habe es mit COALESCE(Spalte1, '') probiert, hat nichts gebracht.

Hab auch das versucht: COALESCE(VARCHAR(8), Spalte1), ''), hat leider auch nicht geholfen.

Vielleicht bin ich auch einfach zu blöd, wäre super wenn einer von euch eine Idee hätte.

Danke im Voraus!

[uenetz]

Wäre es denn nicht besser in ein BIGINT-Feld einen Defaultwert, z.B. 0 zu setzen, anstatt NULL?

[Der Hans]

'' ist ein leerer String, für ein bigint-Feld denkbar ungeeignet.

0 als Standardwert ist auch nicht gut, da dann ein Standardwert von einem "echten" Wert 0 nicht unterschieden werden kann.

Warum soll NULL vermieden werden?

[Enno]

(Big)Int = NULL <=> '' = String

Null ist in den Zahlenfeldern das was in String Feldern '' ist.

Du bekommst bei einem SQL in einem Zahlenfeld also keinen Leerstring hin. Da NULL quasi Leer ist.

[chablife]

Das ist eine Datenbank einer Software bei uns. Jetzt braucht ein Partner von uns paar Daten, um mit denen arbeiten zu können. Die gebe ich ihm über eine Abfrage.

Jetzt meinte er dass der Wert NULL bei den leeren Feldern Probleme bereitet, jedenfalls bräuchte er ein leeres Feld, da er mit dem NULL Wert nicht arbeiten kann. Ich sitze nun hier und versuche die Spalte leer zu machen. 0 darf da auch leider nicht stehen.

Gebe es eine Möglichkeit, das bigint in varchar zu konvertieren? So dass ich dann eben einen leeren String da reinschreibe.

[Der Hans]

Du könntest eine Variable deklarieren, die du mit dem bigint belegst und in der Abfrage per CAST() zum VARCHAR machst. Kombiniert mit einer ISNULL()-Abfrage könntest du das Feld so "leeren".

Ungefähr so:

DECLARE @value bigint

SELECT @value = (SELECT value FROM tbl)


SELECT id

      ,ISNULL(CAST(@value AS VARCHAR), '')

FROM tbl

Meiner Meinung nach extrem hässlich und erklärt nicht, wieso die Lieferung keine NULL-Werte enthalten darf.

[lilith2k3]

Das ist eine Datenbank einer Software bei uns. Jetzt braucht ein Partner von uns paar Daten, um mit denen arbeiten zu können. Die gebe ich ihm über eine Abfrage.

Mal ganz in's Blaue geschossen:

Wie wäre es, wenn Du statt die Datenbank, das Resultset veränderst?

ISNULL (Transact-SQL)

0 als Standardwert ist auch nicht gut, da dann ein Standardwert von einem "echten" Wert 0 nicht unterschieden werden kann.

Ich weiß zwar, dass es semantisch einen Unterschied machen kann, ob ein Wert 0 oder eben Null ist, aber einleuchtend finde ich eine solche Unterscheidung nicht. Man überlädt quasi das Datenfeld mit zwei Bedeutungen. Sowas ist (zwar machbar) in meinen Augen ein Code smell. Vorallem, weil man auf der Gegenseite - unter .NET entweder gezwungen ist, auf Null zu prüfen oder aber mit Nullables zu arbeiten.

Null ist schon aus gutem Grund ein Code Smell in anderen Sprachen (man greift sinnvollerweise auf NullObjects zurück); also sollte es das auch aus SQL gestrichen werden.

Mal abgesehen davon, dass mich mal der Nutzen von Null in Bezug auf Zahlen interessieren würde. Beim Timestamp könnte ich es noch verstehen...

[Der Hans]

NULL ergibt überall da Sinn, wo Werte optional gesetzt werden können. Beispielsweise bei Vorgängen, die zwingend einen Haupt- und optional einen Zweitbearbeiter haben. Wenn ich dort zweitbearbeiter_id = 0 setze, muss ich wiederum in der Bearbeitertabelle einen Eintrag mit der zweitbearbeiter_id = 0 haben, der mir anzeigt, dass es keinen Bearbeiter gibt, da sonst die Verknüpfung nicht korrekt ist. Warum dann nicht direkt mit einem Wert angeben, dass eben kein optionaler Wert vorhanden ist?

Anders sieht es natürlich aus, wenn die Natur der Sache vorgibt, dass immer ein Wert vorhanden ist, beispielsweise bei Kontobeträgen. Wenn ich kein Guthaben habe, dann ist der Wert 0, dort wäre NULL sinnlos.

[chablife]

Hey Leute, ich habe die Lösung.

Die ist so einleuchtend, dass ich mir jetzt blöd vorkomme.

Ich hatte es ja so probiert:

COALESCE(VARCHAR(8), Spalte1), '')

Hat nicht geklappt. Es wurde eine 0 angezeigt. Mit CAST statt CONVERT funktioniert es allerdings:

COALESCE(CAST(Spalte1 AS VARCHAR), '')

Bin nicht auf die Möglichkeit gkommen, CAST zu benutzen, da ich normalerweise immer CONVERT benutze und nie ein Unterschied zwischen beiden sah.

Vielen Dank an alle die mir helfen wollten.

@Der Hans Im Endeffekt ist es ja genauso wie in deinem Beispiel, nur dass ich die Spalte direkt reinschreibe und nicht über eine Variable.

[Enno]

@lillith

Anderes Beispiel.

Du fragst Temperatursensoren ab.

NULL bedeutet dann soviel wie Sensor liefert kein Ergebnis.

0 ist einfach die Temperatur von 0°

Wenn du jetzt NULL auch auf 0 setzen willst geht das nicht. Bzw. geht schon, aber ist eben Falsch.

[lilith2k3]

@lillith

Anderes Beispiel.

Du fragst Temperatursensoren ab.

NULL bedeutet dann soviel wie Sensor liefert kein Ergebnis.

0 ist einfach die Temperatur von 0°

Wenn du jetzt NULL auch auf 0 setzen willst geht das nicht. Bzw. geht schon, aber ist eben Falsch.

Aber gerade das ist doch ein Beispiel für ein falsches Verständnis von NULL.

Wenn ich den Sensor frage: »Welche Temperatur hast Du?«, ist die Antwort »Ich bin kaputt« keine Antwort, die etwas mit der erfragten Temperatur zu tun hat, sondern gibt Auskunft über den Status des Gerätes selbst.

Das ist der Fall, den ich mit Überladung eines Feldes mit zwei Bedeutungen gemeint habe.

Ander ist der oben angegebene Fall, wo ein Verweis nicht gesetzt ist, und deshalb die ID NULL ist.

[Enno]

welchen Wert willst du dann in das Temperaturfeld schreiben?

Du musst für den Zustand des Gerätes in meinem Fall am besten noch ein 2tes Feld mitführen.

Aber einen Wert in die Temperatur schreiben ist IMHO genauso falsch. Da ja eben keine Temperatur gemessen wurde.

[uenetz]

Eine andere Vorgehensweise wäre:

Daten in die Datenbank schreiben, wenn auch welche da sind.

Funktioniert im o.g. Fall der Sensor nicht, so sind auch keine Daten zum Speichern vorhanden.

Aber hier befindet man sich wieder auf einem Pfad der Möglichkeiten, die auf Grund der Gegebenheiten zutreffen können, jedoch nicht müssen, dann zu konkreten Lösungsvorschlägen fehlen einfach einige Informationen.

Bearbeitet 27. Oktober 2014 von uenetz

[Heikooo]

welchen Wert willst du dann in das Temperaturfeld schreiben?

Du musst für den Zustand des Gerätes in meinem Fall am besten noch ein 2tes Feld mitführen.

Aber einen Wert in die Temperatur schreiben ist IMHO genauso falsch. Da ja eben keine Temperatur gemessen wurde.

Im Fall eines Fehlers beim Sensor würde ich die App die das ganze verarbeitet und in die DB einträgt so programmieren, dass sie halt einfach erst gar keine Zeile in die Temperatur-Tabelle schmeisst. Fehler sollten nicht in diese Tabellen...

[RipperFox]

@Heikooo

..und was wäre, wenn z.B. ein Datensatz aus mehreren Sensorwerten besteht? Nur weil einer von 100 Sensoren kein Ergebnis liefert die anderen 99 Messungen wegschmeißen?

"Fehler" sind auch Informationen.

Ich denke chablife musste die Daten nach irgendwas (Excel, CSV, etc.) in eben gegebener Form exportieren - das krieg man eben mit CASE/COALESCE + CAST am einfachsten hin.

[Heikooo]

Wenn 100 Sensoren eine Messung ergeben, würde ich eine Tabelle "Messung" machen in der das Datum der Messung usw steht. Eine weitere Tabelle hat dann die Teilmessungen (also die Ergebnisse der einzelnen Sensoren) mit Fremdschlüssel auf die Messungen... Alle die erfolgreich sind kommen da rein. Wenn man nun wissen will was das ergebnis ist nimmste die netten Aggregatfunktionen und siehst eine durschnittliche Temperatur usw und kannst dann auch mit Count sehen wie viele Sensoren sich dazu herabgelassen haben zu funktionieren

[lilith2k3]

Wenn 100 Sensoren eine Messung ergeben, würde ich eine Tabelle "Messung" machen in der das Datum der Messung usw steht. Eine weitere Tabelle hat dann die Teilmessungen (also die Ergebnisse der einzelnen Sensoren) mit Fremdschlüssel auf die Messungen

Genau. Das wäre in meinen Augen der semantisch korrekte weg.

Eine fehlende Referenz (der Fremdschlüssel darf durchaus mit NULL gefüllt sein) zeigt an, dass die Messung nicht existent ist. Somit hat dieses Feld auch nur eine Bedeutung (Messung existiert/nicht)

[RipperFox]

Das befreit mich aber auch nicht davon, existierende aber ungültige Messwerte dann z.B. mit Messwert "NULL" einzutragen.

Heikooo wollte die ja erst gar nicht abspeichern.

Es ist ein Unterschied, ob eine Messung versucht wurde und kein Ergebnis lieferte oder ob schon der Versuch nicht klappte.

Ausserdem: Denormalisierung

[Heikooo]

Ich würde die auch nicht abspeichern weil das darin nichts zu suchen hat. Du kannst von mir aus noch eine Tabelle "fehlgeschlagene Sensorwerte" oder so anlegen und dort abspeichern für welche Messung welcher Sensor aufgegeben hat. Aber in einer Tabelle wo erfolgreiche Werte rein sollen passt das nicht rein. Wenn du dann wissen willst wie viele Sensoren geklappt haben und wie viele nicht machst du Count... willst du wissen welche Sensoren gesponnen haben dann musst du die Abfrage was anders machen aber das geht so auch. So hast du keine inkonsistenten Daten.

[pr0gg3r]

So hast du keine inkonsistenten Daten.

Hier kommen sich aber die Bereichsintegrität (Wert nicht NULL erwartet) und die logischen Konsistenz (kein Messergebnis ist nicht gleich 0) in die Quere. Man könnte das in der Tat so umsetzen, dass "kein Messergebnis" gar nicht erst (in dieser Tabelle) erfasst wird.

[RipperFox]

Ein NULL Eintrag bei einem Messwert würde ich nicht unbedingt inkonsistent nennen.

Es kommt schon auf das genaue Szenario an, wie man seine Daten ablegt - mach doch mal ein konkretes Beispiel und dann schauen wir uns den Ausführungsplan an.

Wenn Du Texte wie "Vorname", "Zweiter Vorname" und "Nachname" abspeicherst: Was ist dir bei nicht vorhandenem zweitem Vornamen lieber: NULL oder Empty String? Auch da kann man sich ggf. streiten, was "besser" ist oder ggf. mehr Hirnschmalz erfordert.

Auch lesenswert: The HOBT: SQL Server And NULL Values, Revisited

Grüße

Sascha

[lilith2k3]

Wenn Du Texte wie "Vorname", "Zweiter Vorname" und "Nachname" abspeicherst: Was ist dir bei nicht vorhandenem zweitem Vornamen lieber: NULL oder Empty String?

Tja, das ist ein typischer Grenzfall von: »Wie klöppeln wir die Daten SQL-gerecht zusammen?«. Mit spaltenorientierten (wahlweise anderen NoSQL-) Datenbanken wäre das nicht passiert.

Auch lesenswert: The HOBT: SQL Server And NULL Values, Revisited

Der Artikel sagt im Tenor nichts anderes als: »NULL ist 'ne coole Sache. So können wir ein Feld mit zwei Bedeutungen aufladen, weil's das so herrlich einfach macht.« Das macht's für mich nicht schöner.

[Heikooo]

Tja, das ist ein typischer Grenzfall von: »Wie klöppeln wir die Daten SQL-gerecht zusammen?«. Mit spaltenorientierten (wahlweise anderen NoSQL-) Datenbanken wäre das nicht passiert.

Der Artikel sagt im Tenor nichts anderes als: »NULL ist 'ne coole Sache. So können wir ein Feld mit zwei Bedeutungen aufladen, weil's das so herrlich einfach macht.« Das macht's für mich nicht schöner.

So siehts aus

Aber im Grund ist es ja auch egal wie man es nun speichert, ich denke es kommt auch auf den Anwendungsfall an. Ich hätte meine fehlerhaften Sensordaten halt nicht gespeichert weil ich mehr als die Info "hat nicht geklappt" nicht gebraucht hätte und dafür muss ich mir nicht die Datenbank zu müllen sondern kann das per Abfrage klären. Andere wollen vllt speichern was nicht geklappt hat o.Ä. und daher dann die Daten speichern. Wie man jetzt im Endeffekt null nutzt und ob man ein Feld doppelt belädt sei m.M.n. jedem selbst überlassen sofern es funktioniert

[RipperFox]

Ich denke der Artikel zeigt nur, dass man um NULL bei bestimmten Sachen schwer rumkommt, wenn man nicht ins letzte Normalisieren will. NULLs gibt's dank Sparse Columns, etc. auch recht günstig. JOINs nicht unbedingt. Das ist halt das Problem bei relationalen DBs..