Spalte hat den Wert Null und lässt sich nicht updaten

[p80286]

Zitat von jobo:

Zitat von TigerLilly:

ISNULL, IIF, COALESCE, WHEN in Kombination mit NULL sind immer ein Zeichen für mangelhaftes Design.

Nein, bitte! Diese Aussage ist viel zu pauschal. Was soll ein Neuling damit anfangen?
ISNULL() ist genau in Kombination mit einem Nullwert sinnvoll, sogar dafür gemacht.

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, was in der vorliegenden Tabelle wohl der Fall gewesen ist (nur meine Vermutung).

Gruß
K-H

[jobo]

Zitat von p80286:

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

Zitat von himitsu:

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

[TigerLilly]

Zitat von jobo:

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.

Der Vorteil eines sauberen Datenmodells ist, dass es ganz egal ist, wie man drauf zugreift - Multi-Tier, C/S, irgendein Tool oder ein API. Das Datenmodell sichert Integrität und Konsistenz. Ich würde auch bei C/S oder Multi-Tier jedenfalls der DB die Letztprüfung überlassen, was Integrität und Konsistenz betrifft.

Die Basics für jedes Datenmodell:
- Primary keys
- foreign keys/referentielle Integrität
- Defaults/constraints/null/not null
- Normalisierung
- Indices

So wie es beim Programmieren best practices gibt, gibt es die auch beim Umgang mit Datenbanken + man macht sich das Leben leichter, wenn sich dran hält.

[jobo]

Das sehe ich auch so!
Allerdings bewegen wir uns damit ziemlich in die Grundlagen und der TE hat bereits seine Lösung. Ich hab die Einschränkung "separate Persistenzschicht" auch deswegen selbst geliefert, weil wir ja eh schon auf der Pingelig-Ebene sind.
Ich kann natürlich auch mit Persistenzlayer auf Datenbankebene final festlegen, was geht und was nicht. Das ist aber dann ein Mehraufwand, den man irgendwie vertreten muss. Vielleicht ist schon mal jemand (unfreiwillig) in die Verlegenheit gekommen. Erst wird eine schöne Webapplikation gebaut und dann kommen die Kunden auf einmal und wollen das Teil "schräg von der Seite anquatschen". Es kann zu Widersprüchen in den beiden Schichten kommen und die Synchronisierung der Regeln kann aufwändig werden, gerade wenn man aus der Persistenzschicht dann noch Eingabevalidierung gebaut hat und es trotzdem knallt.
Da ist es schön, wenn man ganz old school beim sauberen DM angefangen hat.

Auch heterogene System kann (und soll) man m.E. paarweise als CS betrachten. Responsibility rules oder wie das im Kino so schön heißt: Es kann nur einen geben.

Wir hatten neulich gerade ein Projekt gesehen, das in der Produktion kräftig mit SAP hin und herfunkt (soll), Warenwirftschaft, Tracing usw. am Ende gab es dann eine lustige Forderung, die lautete, dass alles auch funktionieren soll, wenn SAP nicht verfügbar ist.

[p80286]

[OT]
ich gehörte zu den schrägen Vögeln.
Spätestens bei der Konvertierung auf eine neue DB war das ganz nützlich.
[/OT]

Gruß
K-H