Das Implementieren eines Observer-Musters aus einer Datenbank sollte generell vermieden werden.
Wieso den? Es stützt sich auf proprietäre (nicht standardmäßige) Technologie des Anbieters, fördert die Abhängigkeit von Datenbankanbietern und das Support-Risiko und verursacht ein gewisses Aufblähen. Aus Unternehmenssicht kann es, wenn es nicht auf kontrollierte Weise geschieht, wie „Skunkworks“ aussehen – eine ungewöhnliche Implementierung von Verhaltensweisen, die üblicherweise von Anwendungs- und Integrationsmustern und -tools abgedeckt werden. Wenn es auf einer feinkörnigen Ebene implementiert wird, kann es zu einer engen Kopplung an winzige Datenänderungen mit einer großen Menge an unvorhergesehener Kommunikation und Verarbeitung führen, was die Leistung beeinträchtigt. Ein zusätzliches Rädchen in der Maschine kann eine zusätzliche Bruchstelle darstellen – es könnte empfindlich auf Betriebssystem, Netzwerk und Sicherheitskonfiguration reagieren oder es kann Sicherheitslücken in der Technologie des Anbieters geben.
Wenn Sie von Ihrer App verwaltete Transaktionsdaten beobachten:
- Implementieren Sie das Observer-Muster in Ihrer App. Z.B. In Java unterstützen CDI- und Javabeans-Spezifikationen dies direkt, und OO-kundenspezifisches Design gemäß dem Gang Of Four-Buch ist eine perfekte Lösung.
- Optional Nachrichten an andere Apps senden. Filter/Abfangjäger, MDB-Meldungen, CDI-Ereignisse und Webdienste sind ebenfalls nützlich für die Benachrichtigung.
Wenn Benutzer Stammdaten direkt in der Datenbank ändern, dann entweder:
- Stellen Sie eine einzelne Verwaltungsseite in Ihrer App bereit, um die Stammdatenaktualisierung zu steuern ODER
- eine separate Stammdatenverwaltungs-App bereitstellen und Nachrichten an abhängige Apps senden ODER
- (bester Ansatz) Stammdatenbearbeitungen in Bezug auf Qualität (Überprüfungen, Tests usw.) und Timing verwalten (wie Codeänderung behandeln), durch Umgebungen bewerben, Daten bereitstellen und aktualisieren / App in einem verwalteten Zeitplan neu starten
Wenn Sie Transaktionsdaten beobachten, die von einer anderen App verwaltet werden (gemeinsame Datenbankintegration) ODER Sie eine Integration auf Datenebene wie ETL verwenden, um Ihre Anwendung mit Daten zu versorgen:
- versuchen Sie, Datenentitäten nur von einer App schreiben zu lassen (von anderen schreibgeschützt)
- Staging-/ETL-Steuertabelle abfragen, um zu verstehen, welche/wann Änderungen aufgetreten sind ODER
- verwenden Sie eine proprietäre Erweiterung auf JDBC/ODBC-Ebene für Benachrichtigungen oder Abfragen, wie auch in Alex Pooles Antwort ODER erwähnt
- Überlappende Datenoperationen von 2 Apps in einen gemeinsamen SOA-Dienst umzugestalten, kann entweder die Beobachtungsanforderung vermeiden oder sie von einer Datenoperation zu einer SOA-/App-Nachricht auf höherer Ebene heben
- Verwenden Sie einen ESB oder einen Datenbankadapter, um Ihre Anwendung für die Benachrichtigung oder einen WS-Endpunkt für die Massendatenübertragung aufzurufen (z. B. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- Vermeiden Sie die Verwendung von Infrastrukturen für Datenbankerweiterungen wie Pipes oder erweiterte Warteschlangen
Wenn Sie Messaging verwenden (senden oder empfangen), tun Sie dies über Ihre Anwendung(en). Nachrichten von der DB sind ein bisschen wie ein Antimuster. Als letztes Mittel können Trigger verwendet werden, die Webdienste aufrufen (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), aber es ist große Sorgfalt erforderlich, um dies auf sehr grobe Weise zu tun, indem ein Geschäfts-(Unter-)Prozess aufgerufen wird, wenn sich eine Reihe von Daten ändert, anstatt feinkörnige Operationen vom Typ CRUD zu verarbeiten. Am besten lösen Sie einen Job aus und lassen den Job den Webdienst außerhalb der Transaktion aufrufen.
