nicht angemeldet
Moin Sven,
Das ist wahr. Da würde ich mit Triggern arbeiten, um das zu verhindern.
Gibts eigentlich schon schlaue Methoden, diesen applikationsspezifischen Code pfleg- und versionierbar abzulegen?
Es gibt Ansätze, aber noch nichts handfestes. Der üblichste Ansatz sind Migrations mit einem Schema-Dump nach einer neuer Migration. Bei PostgreSQL gibt es ein, zwei interessante Ansätze (z.B. diese Blogpost-Serie), aber das handfesteste, was ich kenne, ist das Management von Rails mit seinen Migrations und dem Schema-Dump (wobei ich auch hier auf SQL-Dump umstelle anstatt eines Ruby-Dumps).
Mir gefällt der Gedanke nicht, dass die Applikation nur funktioniert, wenn die Datenbank ebenfalls ihren Teil des Codes korrekt implementiert bekommen hat.
Ich glaube, von dem Gedanken kann man sich verabschieden. Datenbank und Applikation sind dermaßen miteinander verbunden, dass man ohne dass die Datenbank korrekt implementiert wurde eh nicht arbeiten kann.
Außerdem sollte ein ungültiger bzw. invalider Datenschreibversuch nicht erst in der Datenbank scheitern.
Das ist ein Philosophie-Ansatz. Es gibt Leute, die lagern solche Constraints und Verwaltungsinformationen fast vollständig in die Applikation aus (vielleicht abgesehen von foreign keys und unique constraints) und es gibt Leute, die machen das fast vollständig über die Datenbank. Welchen Weg ein Entwickler gehen will, muss er selber wissen, beide haben Vor- und Nachteile.
Ich persönlich bin früher auch deiner Meinung gewesen, sehe da aber inzwischen keinen Sinn mehr drin und lagere vieles in die Datenbank aus, da sie das strukturell bedingt oft viel einfacher und effizienter kann. Und dabei spreche ich nicht von Format-Validierungen oder so etwas. :-)
LG,
CK