|
AW: Spalte hat den Wert Null und lässt sich nicht updaten
@Walter
Warum ist "ANZAHLMAIL" NULL und nicht 0? Du solltest (falls es möglich ist) einmal von NULL auf 0 umstellen (Default Wert?) und dann hast Du Ruhe. alles andere ist nur ein herumgedoktere an den Symptomen. Gruß K-H |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
Zitat:
ISNULL() ist genau in Kombination mit einem Nullwert sinnvoll, sogar dafür gemacht. Aber vielleicht arbeiten die führenden DB Anbieter bereits daran, ihre Funktionsreferenzen umzugestalten: "Wenn mal etwas schief gegangen ist"/Eigentlich verboten, aber ohne geht's halt nicht. ;) Left joins bspw. produzieren auf geradezu penetrante Art und Weise leere, undefnierte Werte (NULL) in den Ergebnisspalten, mal als Beispiel. Es ist vollkommen legitim, sogar notwendig, mit Hilfe der genannten Funktionen solche Resultate abzufragen/abzufangen. Undefiniert ist halt undefiniert, wo's herkommt ist eine andere Frage, wie man's anpackt wurde ja richtig geschildert. Man muss an der Stelle einfach pingelig sein und Grundlagen lernen. Muss man ja (gerade)in Delphi selbst auch. |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
Zitat:
Gruß K-H |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
Zitat:
aber wenn jemand direkt/explizit ein NULL an das Feld übergibt, dann würde das auch so gespeichert. Nein, per se ist die Definition
Delphi-Quellcode:
und
NULL = Nichts
Delphi-Quellcode:
nicht falsch und könnte für "schnelle" Filter/Suchen/Joins auch so gewollt sein.
Wert>0 = etwas
Aber ja,
Delphi-Quellcode:
statt NULL für Nichts ist ebenfalls nicht falsch.
Anzahl = 0
Beides ist je nach Gutdünken "richtig". |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
Zitat:
ISNULL() ist genau in Kombination mit einem NULL-Wert sinnvoll, sogar dafür gemacht. Und dieser Hinweis ist natürlich auch wichtig, Zitat:
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. |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
:thumb:
Zitat:
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. |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
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. |
AW: Spalte hat den Wert Null und lässt sich nicht updaten
[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 |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 08:25 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz