Implementering af et observatørmønster fra en database bør generelt undgås.
Hvorfor? Den er afhængig af leverandørens proprietære (ikke-standard) teknologi, fremmer databaseleverandørens låsning og supportrisiko og forårsager en smule oppustethed. Fra et virksomhedsperspektiv, hvis det ikke gøres på en kontrolleret måde, kan det ligne "skunkworks" - implementere på en usædvanlig måde adfærd, der almindeligvis er dækket af applikations- og integrationsmønstre og værktøjer. Hvis det implementeres på et finkornet niveau, kan det resultere i tæt kobling til små dataændringer med en enorm mængde uforudset kommunikation og behandling, hvilket påvirker ydeevnen. Et ekstra tandhjul i maskinen kan være et ekstra knækpunkt - det kan være følsomt over for O/S, netværk og sikkerhedskonfiguration, eller der kan være sikkerhedssårbarheder i leverandørteknologi.
Hvis du observerer transaktionsdata, der administreres af din app:
- implementer Observer-mønsteret i din app. For eksempel. I Java understøtter CDI- og javabeans-specifikationer dette direkte, og OO-tilpasset design i henhold til Gang Of Four-bogen er en perfekt løsning.
- send eventuelt beskeder til andre apps. Filtre/interceptorer, MDB-meddelelser, CDI-begivenheder og webtjenester er også nyttige til notifikation.
Hvis brugere direkte ændrer stamdata i databasen, skal du enten:
- giv en enkelt administratorside i din app for at styre opdatering af masterdata ELLER
- giv en separat app til administration af masterdata og send beskeder til afhængige apps ELLER
- (bedste tilgang) administrere masterdataredigeringer med hensyn til kvalitet (gennemgange, test osv.) og timing (behandle det samme som kodeændring), fremme gennem miljøer, implementere og opdatere data / genstarte app til et administreret skema
Hvis du observerer transaktionsdata, der administreres af en anden app (delt databaseintegration), ELLER du bruger integration på dataniveau såsom ETL til at forsyne din applikation med data:
- prøv at få dataenheder skrevet af kun én app (skrivebeskyttet af andre)
- afstemning iscenesættelse/ETL-kontroltabel for at forstå, hvad/hvornår der skete ændringer ELLER
- brug JDBC/ODBC-niveau proprietær udvidelse til notifikation eller polling, som også nævnt i Alex Pooles svar ELLER
- refaktorer overlappende dataoperationer fra 2 apps til en delt SOA-tjeneste kan enten undgå observationskravet eller løfte det fra en datahandling til en SOA/app-meddelelse på højere niveau
- brug en ESB eller en databaseadapter til at påkalde din applikation til notifikation eller et WS-slutpunkt til masseoverførsel af data (f.eks. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- undgå brug af databaseudvidelsesinfrastruktur såsom pipes eller avanceret kø
Hvis du bruger beskeder (send eller modtag), skal du gøre det fra din(e) applikation(er). Beskeder fra DB er lidt af et antimønster. Som en sidste udvej er det muligt at bruge triggere, der påkalder webtjenester (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), men der kræves stor omhu for at gøre dette på en meget grov måde, ved at påberåbe sig en forretnings(under)proces, når et sæt data ændres, i stedet for at knuse finkornede CRUD-operationer. Det er bedst at udløse et job og få jobbet til at ringe til webservicen uden for transaktionen.