Obecně je třeba se vyhnout implementaci vzoru Pozorovatel z databáze.
Proč? Spoléhá na proprietární (nestandardní) technologii dodavatele, podporuje uzamčení databázových dodavatelů a riziko podpory a způsobuje trochu nadýmání. Z podnikového hlediska, pokud to není prováděno kontrolovaným způsobem, může vypadat jako „skunkworks“ – implementující neobvyklým způsobem chování běžně pokryté aplikačními a integračními vzory a nástroji. Je-li implementován na jemnozrnné úrovni, může vést k těsnému propojení s malými změnami dat s velkým množstvím nepředvídané komunikace a zpracování, což má vliv na výkon. Další ozubené kolečko ve stroji může být bodem zlomu navíc – může být citlivé na O/S, síť a konfiguraci zabezpečení nebo může existovat slabá zabezpečení v technologii dodavatele.
Pokud sledujete transakční data spravovaná vaší aplikací:
- implementujte ve své aplikaci vzor Observer. Např. V Javě to specifikace CDI a javabeans přímo podporují a OO vlastní design podle knihy Gang Of Four je perfektním řešením.
- volitelně odesílat zprávy do jiných aplikací. Pro upozornění jsou také užitečné filtry/zachycovače, zprávy MDB, události CDI a webové služby.
Pokud uživatelé přímo upravují kmenová data v databázi, pak buď:
- poskytněte ve své aplikaci jedinou stránku správce, která bude ovládat obnovení kmenových dat NEBO
- poskytněte samostatnou aplikaci pro správu hlavních dat a posílejte zprávy závislým aplikacím NEBO
- (nejlepší přístup) spravovat úpravy kmenových dat z hlediska kvality (recenze, testování atd.) a načasování (zacházet stejně jako změna kódu), propagovat prostřednictvím prostředí, nasazovat a obnovovat data / restartovat aplikaci do spravovaného rozvrhu
Pokud sledujete transakční data spravovaná jinou aplikací (integrace sdílené databáze) NEBO k poskytování dat své aplikaci používáte integraci na úrovni dat, jako je ETL:
- snažte se nechat datové entity zapisovat pouze jednou aplikací (ostatní pouze pro čtení)
- staging průzkumu/kontrolní tabulka ETL, abyste pochopili, jaké/kdy nastaly změny NEBO
- použijte proprietární rozšíření na úrovni JDBC/ODBC pro oznámení nebo dotazování, jak je uvedeno v odpovědi Alexe Poole NEBO
- Refaktoring překrývajících se datových operací ze 2 aplikací do sdílené služby SOA se může buď vyhnout požadavku na pozorování, nebo jej přesunout z datové operace na vyšší úroveň SOA/zprávy aplikace
- použijte ESB nebo databázový adaptér k vyvolání vaší aplikace pro oznámení nebo koncový bod WS pro hromadný přenos dat (např. Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- vyhněte se používání infrastruktury rozšíření databáze, jako jsou kanály nebo pokročilé řazení do front
Používáte-li zasílání zpráv (odesílat nebo přijímat), udělejte tak ze své aplikace (aplikací). Zasílání zpráv z DB je trochu antipattern. Jako poslední možnost je možné použít spouštěče, které vyvolávají webové služby (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), ale vyžaduje to velkou péči, abyste to udělali velmi hrubým způsobem, kdy se při změně sady dat vyvolá obchodní (dílčí) proces, spíše než křupání jemnozrnných operací typu CRUD. Nejlepší je spustit úlohu a nechat ji zavolat webovou službu mimo transakci.