..
Entschuldige, aber Deine Formulierung ist mißverständlich. das Datenbank-NULL ist gleichbedeutend mit "Nix,Niente,dat jibbet nich" (nicht vorhanden!). Währen "Null" gerne mit "0" gleichgesetzt wird, ..
Ja, richtig, wer Pingeligkeit verlangt, sollte das auch selbst einhalten, Präzisierung:
ISNULL() ist genau in Kombination mit einem NULL-Wert sinnvoll, sogar dafür gemacht.
Und dieser Hinweis ist natürlich auch wichtig,
..Ein DEFAULT ohne das zugehörende NOT NULL wird nicht das Problem lösen..
allerdings ebenfalls missverständlich. "das zugehörende NOT NULL" würde in diesem Fall hier (Thread) da"zugehören" und die Sache wasserdicht machen, in vielen anderen Fällen sicher auch. Es ist aber nicht per se "zugehörend" zur DEFAULT Angabe und damit ebenfalls zu pauschal formuliert.
DEFAULT Angabe, NOT NULL Constraint sowie beliebige andere Spalten-Constraints sind beides optionale Angaben.
Was eben keineswegs bedeutet, dass es eine Sache für Pedanten oder Kosmetik Freaks ist.
Das Wichtige an diesen Dingen ist m.E., dass man mit ein paar Wörtchen mehr im Datenmodell ziemlich haargenau festlegen kann, wie die Sache laufen soll und sich damit oftmals eine Menge Code, Fehlerbehandlung und vor allem auch Fehlersuche erspart.
Um Einwänden vorzugreifen:
Auch ein sinnvoller, richtiger, wichtiger Datenbank Constraint ändert natürlich nichts daran, dass ein (häßlicher) Fehler auftaucht, wenn der Konstraint verletzt wird. Und das muss natürlich behandelt werden. Diese Behandlung kann aber ziemlich pauschal erfolgen, sinngemäß ungefähr "Der Meister hat bestimmt, dass diese Eingaben unzulässig sind". Das passt immer, wenn man sich (richtige) Gedanken über das Datenmodell gemacht und diese umgesetzt hat.
Noch mehr Blabla
Der entscheidende Punkt ist dabei, dass das Datenmodell per Definition für Datenkonsistenz sorgen soll. Demnach spart man sich in Folge die mühsame Suche und oder Bereinigung falscher Daten und ebenso Programmcode, der das "überwacht". (auch Anlass dieses Threads)
Das gilt dann immer, auch in jeglicher Situation, in der Datenmanipulation jenseits der Anwendung erfolgt, durch Import von Fremddaten, administrative DML, heterogene Clients (bswp. auch Versionswechsel des eigenen Programms)
Ergebnis: Meine Business Logik, die Reports, die Dashboards stimmen immer. Fall-basierter Code läuft niemals in undefinierte Bereiche.
Das ist allerdings eine Betrachtungsweise, die nur greift, wenn ich mich im Rahmen eines Client/Server Konzepts bewege. Werden separate Persistenzschichten genutzt, verlagert sich die Hoheit über die Datenkonsistenz (und das gesamte Modell) in diese Schicht.