Diskussion Fragen zu CleanCode und Datenbankdesign

R

rammi22

Neues Mitglied
Weil ich im Zweifel bin, würde ich mir hier gern Meinungen einholen:

Folgendes Szenario:
  • Datenbank Entity mit Attribute xyz, erlaubt ist NULL oder string
  • beim Auslesen der Entity wird Attribute xyz wenn NULL mittels eines Skript mit Daten befüllt
  • beim Speichern wird ohne Nachfrage nun dieser skriptseitig erstellte Wert in die Datenbank geschrieben
mMn ist das ein schlechtes Design, da Usereingaben überschrieben werden ohne Rückmeldung.

Fragen (aus der Sicht sauberer Programierung):
  • Verstösst ein solches Design gegen Programmierregeln, wenn ja, welche?
  • Ist das Überschreiben von Usereingaben skriptseitig nicht kritisch?
  • Welche Szenarien könnten für einen solche Programmierung sprechen?
 
Zuletzt bearbeitet von einem Moderator:
Ich würde sagen das hängt stark vom Kontext und den Usereingaben ab. Wofür wird das Ganze gemacht?

Außerdem verstehe ich dich so, dass nur Daten überschrieben werden, wenn vorher NULL eingetragen war, sprich keine Daten vorhanden waren.
 
Fallbackwerte sind etwas ganz natürliches und man sollte sich nicht dafür schämen.

Beim Auslesen werden diese Fallbacks geladen und dem User gezeigt, oder? Wenn die User nun speichern, speichern sie gezielt die neuen Werte mit ab. Das ist schon ganz ok.

Es kann gute Gründe geben, warum der Defaultwert nicht schon direkt in der DB gesetzt wird und NULL zeigt eindeutig, dass das Feld unbelegt ist (im Gegensatz zu einem leeren String ""). Also hängt stark vom Anwendungsfall ab. Grundsätzlich sollte gelten, dass die DB sich nur um die Daten und ihre Integrität kümmern sollte. Deswegen kann es schon ganz gut sein, dass erst das Skript sich um die Logik kümmert.

Unsauber könnte es sein, wenn NULL genutzt wird, um festzustellen ob eine Entität neu initialisiert wurde oder bereits vorhanden war, usw.

Hmm..wenn ich müde bin, schreibe ich wie ChatGPT. :poop:
 
Erstmal Danke für die Antworten (y)
@Mat
Unsauber könnte es sein, wenn NULL genutzt wird, um festzustellen ob eine Entität neu initialisiert wurde oder bereits vorhanden war, usw
Zum Vergrößern anklicken....
Was meinst du damit? Eine Prüfung wie diese:
Code: 
if (!myEntity.xyz) { 
   // do what with this. e.g set attribute values
}
 
Die Prüfung in deinem Beispiel fällt eher noch unter "Fallback-Werte laden". Also wenn diese Aktion immer richtig ist, egal ob der Datensatz neu oder alt ist, dann ist das in Ordnung.

Wenn da noch einmalige Aktionen von der Prüfung ausgelöst werden können, kann das schon zu Problemen führen.

Mal ein unrealistisches Szenario zur Veranschaulichung
Du hast einen Webshop für Hundespielzeug. Die Seite wurde von JavaScript-Justus geschrieben, der noch zur Schule geht. Sein Herz ist am rechten Fleck, aber er weiß ehrlich gesagt gar nicht so recht, was er da macht. Eigentlich wollte er das gar nicht machen, aber seine Tante hat ihn regelrecht dazu genötigt.

Er ist schon froh, dass der Shop trotz der vielen kryptischen Fehlermeldungen überhaupt läuft. Seine Tante kommt jedoch immer mit neuen Extrawünschen: zuletzt mit der Idee, allen Usern bei der nächsten Bestellung einen 5% Rabattcode in den Warenkorb zu legen.

Justus weiß nicht weiter und die Zeit drängt. Also fügt er der User-Tabelle kurzerhand das Feld "Rabattaktion" hinzu, mit NULL. Wenn der User den Warenkorb öffnet und das Feld "Rabattaktion" NULL ist, dann wird der Rabattcode als Artikel hinzugefügt. Nach erfolgreicher Bezahlung wird das Feld überschrieben mit "1".

Das scheint auch alles zu klappen, aber nach 2 Wochen meldet sich seine Tante und beschwert sich darüber, dass plötzlich in jeder zweiten Bestellung eines Kunden 5% abgezogen werden.

Was ist passiert? Warenkörbe ohne Rabattcode haben das Feld wieder genullt. Die Prüfung hat der NULL vertraut. Ein Kunde hat also etwas mit Rabatt bestellt, dann wurde das Feld auf "1" gesetzt. Beim nächsten Mal war kein Rabattcode im Warenkorb und das Feld wurde wieder auf NULL gesetzt. In der darauffolgenden Bestellung wurde der Rabattcode wieder hinzugefügt.

Fazit
Ein Feld bei einer Prüfung mit Standardwerten belegen ist völlig in Ordnung. Hingegen kann das Anstoßen von komplexeren Prozessen als Reaktion auf genullte Felder gefährlich sein. Besonders, wenn irgendwann in eine neue Tabellenstruktur migriert wird.
 
Zurück
Oben Unten