SQL-Datenbanktrigger sollten idealerweise die Papierkorbfunktion ebenfalls unterstützen, d. h. Berechnungen wie Summe oder Anzahl dürften dann keine Datensätze berücksichtigen, bei denen die Papierkorb-ID nicht leer ist.
SQL-Datenbanktrigger, die Berechnungen durchführen ("Anzahl Teilnehmer" o. ä.), müssen (ggf. zusätzlich zum bisherigen INSERT/DELETE) auf ein UPDATE der Papierkorb-ID "scharf gestellt" werden. Wird die Papierkorb-ID auf NULL gesetzt, so wird der Datensatz gerade aus dem Papierkorb wiederhergestellt, wird diese auf eine konkrete GUID gesetzt, so wird der Datensatz gerade in den Papierkorb verschoben.
Möglicherweise muss der Trigger auch "schlauer" werden als bislang notwendig. Nämlich falls das Wiederherstellen eines gelöscht markierten Datensatzes zu einer problematischen Dublette führen könnte. Dieses Szenario war bislang ohne Papierkorb nicht möglich. Dies muss für den konkreten Business Case analysiert und entschieden werden. Verteilerzuordnungen oder Teilnehmerzuordnungen sind hier potentielle Problembaustellen. Anwender A löscht eine solche Kontakt-Zuordnung in den Papierkorb, Anwender B legt Tage später für denselben Kontakt eine solche Zuordnung neu an und eine Woche später stellt Anwender A die einstige Kontakt-Zuordnung aus dem Papierkorb wieder her. Jetzt ist der Kontakt zweimal in der Zuordnungsliste!