Datenbanknormalisierung

[Steffen]

Hallo!

Wenn das Projekt so ausgelegt ist, dass nur eine einzige Applikation (abgesehen von Admin-Tools) auf den Datenbestand zugreift, warum soll dann nicht diese Applikation selbst für die Datengültigkeit sorgen?
Ich finde schon, dass das nach Möglichkeit in der DB passieren sollte. Das ist das, was eine DB (u.a.) gut kann.
Das fängt mMn schein bei einfachen "not null" und "foreign keys" Contraints an. Willst Du sowas alles in der Applikation machen? Absolut nicht sinnvoll. Das bläst den Applikationscode unnötig auf.

"Absolut"? Ich finde es aber auch nicht sinnvoll, wenn die Applikation die meiste Zeit in catch-Bereichen verbringt, nur weil sie kein bisschen darauf achtet, was die Datenbank mag und was nicht. Die App sollte schon dem Schema entsprechend angelegt sein.

Auf alle Fälle. Fehler sollte für den Benutzer so-und-so keine auftauchen. Also muss das UI schon so angelegt sein, dass der Benutzer nicht leer lassen kann.

Ein catch ist dafür aber auch nicht sinnvoll, weil die App sollte zu DB passen. Somit kann dieser Fehler gar nicht auftreten. Wenn es doch zu einem Fehler kommt ist es egal, ob von der DB oder von der App generiert.

Wenn im DBMS kein Null-Wert abgelegt werden kann, sollte auch die Anwendung nicht für dieses Feld mit Null-Werte arbeiten können und erst beim Insert auf die Nase fallen. Ich sehe es auch nicht als besonders sinnvoll an, sämtliche andere Datenvalidation in Stored Procedures oder ähnliches zu stecken.

Sag ich ja. Ich habe es zwar eher an SELECTs gedacht, aber wenn 'not-null' -> ich kann mich darauf verlassen, dass da ein Wert ist.

Aber es muss jeder für sich selber entscheiden, wie weit er geht. Ich finde jedenfalls, dass sich Datenkonsistenz wesentlich einfacher und mit viel weniger Code in der DB erzeugen lässt; nicht in der Applikation. Und konsistente Daten machen die Applikation schlanker.

Grüße

• Steffen