डेटा परिवर्तनों का प्रभावी प्रबंधन

इसके विपरीत, जिस पारंपरिक डेटाबेस का हम अस्थायी सुविधाओं के बिना उपयोग करते हैं, उसे वर्तमान डेटाबेस . कहा जा सकता है ।

एक वर्तमान डेटाबेस . में , यदि आप अस्थायी समर्थन को लागू करने का प्रयास करते हैं, तो आप विभिन्न तरीकों से कई तरह से विफल हो सकते हैं:

• एक-तालिका दृष्टिकोण। जब आपको संशोधन करने की आवश्यकता होती है, तो आप UPDATEs करते हैं आपके मूल रिकॉर्ड पर, और जब तक आपके पास किसी प्रकार का घरेलू ट्रिगर/ऑडिट लॉजिक न हो, इतिहास का निशान अनुपस्थित है। यहां तक ​​कि अगर आपके पास ऑडिट/परिवर्तन लॉग है, तो आपको परिवर्तन इतिहास को फिर से बनाने के लिए कुछ बदसूरत खुदाई करनी होगी।

• दो-तालिका दृष्टिकोण। जगह-जगह संशोधन करने के बजाय, आप अपने डेटा को दो तालिकाओं में विभाजित करते हैं, एक आधार/मूल रिकॉर्ड (जैसे बुकिंग) के साथ, और दूसरी तालिका आपके परिवर्तन/संशोधन/डेल्टा के लिए। फिर कम से कम आपके पास अपना मूल डेटा संरक्षित है, लेकिन फिर से आपको मूल डेटा को स्तरित संशोधनों के साथ देखने के लिए जटिल तर्क लिखना होगा। यह और भी बुरा हो जाता है यदि आप केवल कुछ चाहते हैं लागू किए गए संशोधनों में से।

• पूर्व परिकलित परिणामी तालिका दृष्टिकोण . आप 3 या अधिक टेबल रखते हैं:आधार रिकॉर्ड, संशोधन, और एक तालिका जो हमेशा परिणामी होने का प्रयास करती है (आधार + संशोधनों को अद्यतित रखती है)। जब भी आप INSERTs करते हैं, तो इस गणना को करने के लिए ट्रिगर्स और प्रक्रियाओं को लिखने का सौभाग्य प्राप्त करें , और स्वर्ग आपकी सहायता करता है यदि कोई UPDATEs या DELETE ज़रूरी है। सेटअप नाजुक है और गतिरोध और रोलबैक जैसे सिंक से बाहर हो सकता है। यदि आप इसे ट्रिगर्स/प्रक्रियाओं के साथ डीबी के भीतर नहीं करते हैं, तो आप परिणामी गणना को एप्लिकेशन कोड में लागू करने का प्रयास कर सकते हैं, लेकिन उस पर अच्छी किस्मत है - और यह बहु-थ्रेडेड उपभोक्ताओं के साथ बदसूरत हो सकता है। और फिर भी, आपके पास केवल कुछ . के साथ परिणामों तक आसान पहुंच नहीं है संशोधन लागू।

निष्कर्ष: यदि आप MySQL तक सीमित नहीं हैं, तो आपको वास्तव में एक डीबी का उपयोग करने पर विचार करना चाहिए जिसमें अंतर्निहित अस्थायी समर्थन है। अन्यथा, आप पहिया को फिर से लागू करने जा रहे हैं।