nicht angemeldet
Hi,
Man kann in der Datenzugriffsschicht grundsaetzlich alles machen, was die Trigger in der Datenschicht so machen. Ich sehe eigentlich nur einen sinnvollen Einsatz fuer Trigger fuer Alerts (Mitarbeiter X erfahert eine Aenderung des Datenfelds 'Monatsgehalt' in der Mitarbeitertabelle => Mail an den Personalchef.).
Die Datenbank kann auf jeden Fall diese Beschränkungen und Kaskadierungen schnell und zuverlässig ausführen; der aktive Zugriff über SQL kostet mehr.
Performancefragen wuerde ich gerne zuletzt behandeln. Denn erst einmal kostet der Programmierergrips. (Wenn ich da mal einen Tipp an den Nicht-Praktiker(? ;-) geben darf: _unbedingt_ Komplexitaet vermeiden, d.h. moeglichst wenig Komplexitaet hinzubauen)
Allerdings ist meine Meinung da recht unsicher und unbestaetigt. Es ist schon interessant den Datendesigner bestimmte Datenzugriffe (kaskadierende Deletes und Trigger) bereits in seiner Datenschicht durchfuehren zu lasssen. Mein Gegenargument ist die Komplexitaet ("Ein kaskadierendes Delete hat den Delete-Trigger x ausgloest, der wiederum den Delete-Trigger y ausgeloest hat. Nun haben wir alle Datensaetze der Tabelle z geloescht, die im Jahr 1994 angelegt wurden." :-( :-)
Wenn Du Angst hast, auf dieser Ebene etwas falsch zu machen (Du hast doch sicher immer ein Backup?), wie kommst Du dann darauf, dass Deine auf höherer Ebene programmierten äquivalenten Mechanismen zuverlässiger und weniger gefährlicher sind bzw. wären?
Ich habe nie Angst davor etwas falsch zu machen. ;-)
Wir hatten schon mal so "Studis" hier, frisch von der Uni, die haben auch die Einfachheit nicht geschaetzt (und versuchten das mit Sprachgewandheit zu kompensieren). Programmierfehler koennen natuerlich ueberall passieren.
Aber wer kann solche sehr schwierigen Fragen heute noch zuverlaessig beantworten? ;-)
Wenn überhaupt jemand, dann natürlich ich. Und ich sage: Constraints und Trigger sind toll! So!
Ich wuerde es gerne mal mit einem "aktiven" Datendesign und mit Triggern (die mag ich allerdings weniger) und kaskadierenden Deletes versuchen. Constraints (Du meinst Fremdschluessel und Check-Constraints, vermute ich (fuer die Integritaeten und so)) sind m.E. ebenso etwas zweifelhaft (aeeh, nicht die ref.Integritaet, dafuer bin ich dem RDBMS schon dankbar).
Also, man kann moeglichst viel in der Datenschicht machen oder moeglichst wenig dort (meine bisherieg Empfehlung).
Eine Aufforderung zur Meinungsaeusserung ergeht hiermit!
Gruss,
Ludger