Att implementera ett observatörsmönster från en databas bör i allmänhet undvikas.
Varför? Den förlitar sig på leverantörens proprietära (icke-standard) teknologi, främjar inlåsning av databasleverantörer och supportrisk, och orsakar lite svullnad. Ur ett företagsperspektiv, om det inte görs på ett kontrollerat sätt, kan det se ut som "skunkworks" - implementera på ett ovanligt sätt beteende som vanligtvis täcks av applikations- och integrationsmönster och verktyg. Om det implementeras på en finkornig nivå kan det resultera i en tät koppling till små dataförändringar med en enorm mängd oförutsedd kommunikation och bearbetning, vilket påverkar prestandan. En extra kugg i maskinen kan vara en extra brytpunkt - den kan vara känslig för O/S, nätverk och säkerhetskonfiguration eller så kan det finnas säkerhetsbrister i leverantörsteknik.
Om du observerar transaktionsdata som hanteras av din app:
- implementera Observer-mönstret i din app. T.ex. I Java stöder CDI och javabeans specifikationer detta direkt, och OO anpassad design enligt Gang Of Four-boken är en perfekt lösning.
- Skicka eventuellt meddelanden till andra appar. Filter/interceptorer, MDB-meddelanden, CDI-händelser och webbtjänster är också användbara för avisering.
Om användare direkt ändrar masterdata i databasen, gör antingen:
- tillhandahåll en enkel administratörssida i din app för att styra uppdatering av masterdata ELLER
- tillhandahålla en separat app för hantering av masterdata och skicka meddelanden till beroende appar ELLER
- (bästa tillvägagångssätt) hantera masterdataredigeringar när det gäller kvalitet (granskningar, testning, etc) och timing (behandla samma sak som kodändring), främja genom miljöer, distribuera och uppdatera data / starta om appen till ett hanterat schema
Om du observerar transaktionsdata som hanteras av en annan app (delad databasintegration) ELLER använder du integrering på datanivå som ETL för att förse din applikation med data:
- försök att ha dataenheter skrivna av bara en app (skrivskyddad av andra)
- undersökningsstaging/ETL-kontrolltabell för att förstå vad/när förändringar inträffade ELLER
- använd JDBC/ODBC-nivå proprietärt tillägg för meddelanden eller polling, vilket också nämns i Alex Pooles svar ELLER
- refaktorerar överlappande dataoperationer från två appar till en delad SOA-tjänst kan antingen undvika observationskravet eller lyfta det från en dataoperation till ett SOA-/appmeddelande på högre nivå
- använd en ESB eller en databasadapter för att anropa din applikation för avisering eller en WS-slutpunkt för bulkdataöverföring (t.ex. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- undvik användning av databastilläggsinfrastruktur såsom pipes eller avancerad kö
Om du använder meddelanden (skicka eller ta emot), gör det från din(a) applikation(er). Meddelanden från DB är lite av ett antimönster. Som en sista utväg är det möjligt att använda triggers som anropar webbtjänster (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), men stor noggrannhet krävs för att göra detta på ett mycket grovt sätt, genom att anropa en affärsprocess (under)process när en uppsättning data ändras, snarare än att knäcka finkorniga operationer av CRUD-typ. Bäst att trigga ett jobb och låta jobbet ringa webbtjänsten utanför transaktionen.