M1ke:
Σκεφτόμουν ότι οι triggers είναι μια αρκετά δομημένη προσέγγιση για την ακεραιότητα της βάσης, οπότε και αναρωτιέμαι για το ακόλουθο σενάριο (σε SQL Server 2005 SP2):
Κατ' εμέ οι triggers αποτελούν την τελευταία λύση στο θέμα της ακεραιότητας. Τσακίζουν το scalbility...
M1ke: Έχουμε στη βάση ένα trigger που εκτελείται on update ενός πίνακα, πχ CUSTOMER.
Εκτελούμε μία stored procedure που κάνει update τον πίνακα CUSTOMER, και αμέσως μετά το commit της transaction το σύστημα πέφτει.
Μετά το recovery θα εκτελεστεί ο trigger?
Κατά το recovery λαμβάνεται υπόψην η κατάσταση του κάθε transaction που έχει καταγραφεί στο transaction log αλλά δεν έχει περάσει στη βάση. Άρα, αν στο transaction log έχει καταγραφεί ένα commited transaction, γίνονται "redo" οι αντίστοιχες ενέργειες. Αν έχει καταγραφεί ένα uncommited ή rolled back transaction, γίνοται "undo" αντίστοιχα. Τα ίδια ισχύουν και για ό,τι κάνει ο trigger. Όπως και να έχει όμως, ο trigger αποτελεί - implicitly - τμήμα του transaction που τον έχει ξεκινήσει, άρα το παράδειγμά σου δεν υφίσταται 
Δηλαδή αν έχει γίνει commit το transaction, πάει να πει ότι θα έχει τελειώσει τη δουλειά του ο trigger.
Vir prudens non contra ventum mingit