डेटाबेस से ऑब्जर्वर पैटर्न को लागू करने से आम तौर पर बचा जाना चाहिए।
क्यों? यह विक्रेता स्वामित्व (गैर-मानक) तकनीक पर निर्भर करता है, डेटाबेस विक्रेता लॉक-इन और समर्थन जोखिम को बढ़ावा देता है, और थोड़ा सा ब्लोट का कारण बनता है। एक उद्यम के दृष्टिकोण से, यदि नियंत्रित तरीके से नहीं किया जाता है, तो यह "स्कंकवर्क्स" जैसा दिख सकता है - एक असामान्य तरीके से लागू करना जो आमतौर पर एप्लिकेशन और एकीकरण पैटर्न और टूल द्वारा कवर किया जाता है। यदि इसे बारीक स्तर पर लागू किया जाता है, तो यह प्रदर्शन को प्रभावित करते हुए, अप्रत्याशित संचार और प्रसंस्करण की एक बड़ी मात्रा के साथ छोटे डेटा परिवर्तनों को तंग-युग्मन कर सकता है। मशीन में एक अतिरिक्त कॉग एक अतिरिक्त ब्रेकिंग पॉइंट हो सकता है - यह ओ/एस, नेटवर्क और सुरक्षा कॉन्फ़िगरेशन के प्रति संवेदनशील हो सकता है या विक्रेता तकनीक में सुरक्षा कमजोरियां हो सकती हैं।
यदि आप अपने ऐप द्वारा प्रबंधित लेन-देन संबंधी डेटा देख रहे हैं:
- अपने ऐप में ऑब्जर्वर पैटर्न लागू करें। उदा. जावा में, CDI और javabeans स्पेक्स सीधे इसका समर्थन करते हैं, और Gang Of Four किताब के अनुसार OO कस्टम डिज़ाइन एक सही समाधान है।
- वैकल्पिक रूप से अन्य ऐप्स को संदेश भेजें। अधिसूचना के लिए फिल्टर/इंटरसेप्टर, एमडीबी संदेश, सीडीआई इवेंट और वेब सेवाएं भी उपयोगी हैं।
यदि उपयोगकर्ता सीधे डेटाबेस में मास्टर डेटा को संशोधित कर रहे हैं, तो या तो:
- मास्टर डेटा रीफ़्रेश को नियंत्रित करने के लिए अपने ऐप के भीतर एक विलक्षण व्यवस्थापक पृष्ठ प्रदान करें या
- एक अलग मास्टर डेटा प्रबंधन ऐप प्रदान करें और आश्रित ऐप्स को संदेश भेजें या
- (सर्वश्रेष्ठ तरीका) गुणवत्ता (समीक्षा, परीक्षण, आदि) और समय (कोड परिवर्तन के समान व्यवहार करें) के संदर्भ में मास्टर डेटा संपादन प्रबंधित करें, वातावरण के माध्यम से प्रचार करें, डेटा को तैनात और रीफ्रेश करें / एक प्रबंधित शेड्यूल में ऐप को पुनरारंभ करें
यदि आप किसी अन्य ऐप (साझा डेटाबेस एकीकरण) द्वारा प्रबंधित लेन-देन संबंधी डेटा देख रहे हैं या आप डेटा के साथ अपने एप्लिकेशन को प्रदान करने के लिए ईटीएल जैसे डेटा-स्तरीय एकीकरण का उपयोग करते हैं:
- कोशिश करें कि डेटा इकाइयां केवल एक ऐप द्वारा लिखी गई हों (केवल अन्य लोगों द्वारा पढ़ने के लिए)
- मतदान मंचन/ETL नियंत्रण तालिका यह समझने के लिए कि क्या/कब परिवर्तन हुए या
- सूचना या मतदान के लिए JDBC/ODBC- स्तर के मालिकाना विस्तार का उपयोग करें, जैसा कि एलेक्स पूल के उत्तर में उल्लिखित है या
- एक साझा SOA सेवा में 2 ऐप्स से डेटा संचालन को ओवरलैप करने वाले रिफैक्टर या तो अवलोकन आवश्यकता से बच सकते हैं या इसे डेटा ऑपरेशन से उच्च स्तर SOA/ऐप संदेश तक उठा सकते हैं
- अधिसूचना के लिए अपने आवेदन को आमंत्रित करने के लिए किसी ESB या डेटाबेस एडेप्टर का उपयोग करें या बल्क डेटा ट्रांसफर के लिए WS एंडपॉइंट का उपयोग करें (जैसे Apache Camel, Apache ServiceMix, Mule ESB, Openadaptor)
- पाइप या उन्नत कतार जैसे डेटाबेस एक्सटेंशन के बुनियादी ढांचे के उपयोग से बचें
यदि आप मैसेजिंग (भेजें या प्राप्त करें) का उपयोग करते हैं, तो इसे अपने एप्लिकेशन से करें। डीबी से मैसेजिंग एक एंटीपैटर्न का एक सा है। अंतिम उपाय के रूप में, ट्रिगर्स का उपयोग करना संभव है जो वेब सेवाओं का आह्वान करते हैं (http://www.oracle.com/technetwork/developer-tools/jdev/dbcalloutws-howto-084195.html ), लेकिन इसे बहुत ही मोटे तरीके से करने के लिए बहुत सावधानी की आवश्यकता होती है, एक व्यवसाय (उप) -प्रक्रिया को लागू करते हुए जब डेटा का एक सेट बदलता है, बजाय बारीक सीआरयूडी प्रकार के संचालन को क्रंच करने के। किसी कार्य को ट्रिगर करने और कार्य को लेन-देन के बाहर वेब सेवा को कॉल करने के लिए सर्वोत्तम है।
