डेटाबेस में इतिहास पंक्ति प्रबंधन

पहला सवाल होना चाहिए:आप उस डेटा का क्या करेंगे? यदि आपके पास स्पष्ट व्यावसायिक आवश्यकता नहीं है, तो ऐसा न करें।

मैंने कुछ ऐसा ही किया और 3 साल चलने के बाद "वैध डेटा" का लगभग 20% है और बाकी "पिछले संस्करण" हैं। और यह 10 मिलियन + 40 मिलियन रिकॉर्ड है। पिछले तीन वर्षों में हमारे पास परिवर्तनों के इतिहास की जांच करने के लिए 2 (दो) अनुरोध थे और दोनों बार अनुरोध मूर्खतापूर्ण थे - हम रिकॉर्ड परिवर्तन का समय टिकट रिकॉर्ड करते हैं और हमें यह जांचने के लिए कहा गया था कि क्या व्यक्तियों ने ओवरटाइम (शाम 5 बजे के बाद) काम किया है।

अब, हम बड़े आकार के डेटाबेस के साथ फंस गए हैं जिसमें 80% डेटा है जिसकी किसी को आवश्यकता नहीं है।

संपादित करें:

चूंकि आपने संभावित समाधान मांगे थे, इसलिए मैं वर्णन करूंगा कि हमने क्या किया। यह उस समाधान से थोड़ा अलग है जिस पर आप विचार कर रहे हैं।

1. सभी तालिकाओं में सरोगेट प्राथमिक कुंजी होती है।
2. सभी प्राथमिक कुंजियाँ एकल अनुक्रम से उत्पन्न होती हैं। यह ठीक काम करता है क्योंकि Oracle संख्याएँ उत्पन्न और कैश कर सकता है, इसलिए यहाँ कोई प्रदर्शन समस्या नहीं है। हम ओआरएम का उपयोग करते हैं और हम चाहते हैं कि प्रत्येक वस्तु स्मृति (और डेटाबेस में संबंधित रिकॉर्ड) में अद्वितीय पहचानकर्ता हो
3. हम ORM का उपयोग करते हैं और डेटाबेस तालिका और वर्ग के बीच मैपिंग जानकारी विशेषताओं के रूप में होती है।

हम निम्नलिखित स्तंभों के साथ एकल संग्रह तालिका में सभी परिवर्तनों को रिकॉर्ड करते हैं:

• आईडी (सरोगेट प्राथमिक कुंजी)
• समय टिकट
• मूल तालिका
• मूल रिकॉर्ड की आईडी
• उपयोगकर्ता आईडी
• लेनदेन प्रकार (सम्मिलित करें, अपडेट करें, हटाएं)
• डेटा को varchar2 फ़ील्ड के रूप में रिकॉर्ड करें
  • यह फ़ील्डनाम/मान जोड़े के रूप में वास्तविक डेटा है।

चीज़ इस तरह काम करती है:

• ORM ने कमांड को सम्मिलित/अद्यतन और हटा दिया है।
• हमने अपनी सभी व्यावसायिक वस्तुओं के लिए एक आधार वर्ग बनाया है जो इन्सर्ट/अपडेट को ओवरराइड करता है और कमांड को हटाता है
  • इन्सर्ट/अपडेट/डिलीट कमांड्स रिफ्लेक्शन का उपयोग करके फील्डनाम/वैल्यू पेयर के रूप में स्ट्रिंग बनाते हैं। कोड मैपिंग जानकारी की तलाश करता है और फ़ील्ड का नाम, संबद्ध मान और फ़ील्ड प्रकार पढ़ता है। फिर हम JSON के समान कुछ बनाते हैं (हमने कुछ संशोधन जोड़े)। जब वस्तु की वर्तमान स्थिति का प्रतिनिधित्व करने वाली स्ट्रिंग बनाई जाती है, तो उसे संग्रह तालिका में डाला जाता है।
• जब नई या अद्यतन वस्तु को डेटाबेस तालिका में सहेजा जाता है, तो इसे उसकी लक्ष्य तालिका में सहेजा जाता है और साथ ही हम संग्रह तालिका में वर्तमान मान के साथ एक रिकॉर्ड सम्मिलित करते हैं।
• जब ऑब्जेक्ट हटा दिया जाता है, तो हम उसे उसकी लक्ष्य तालिका से हटा देते हैं और साथ ही हम संग्रह तालिका में एक रिकॉर्ड सम्मिलित करते हैं जिसमें लेनदेन प्रकार ="DELETE" होता है

प्रो:

• हमारे पास डेटाबेस में प्रत्येक तालिका के लिए संग्रह तालिकाएँ नहीं हैं। स्कीमा में परिवर्तन होने पर हमें संग्रह तालिका को अपडेट करने के बारे में चिंता करने की आवश्यकता नहीं है।
• पूर्ण संग्रह को "वर्तमान डेटा" से अलग किया जाता है, इसलिए संग्रह डेटाबेस पर कोई प्रदर्शन हिट नहीं लगाता है। हम इसे अलग डिस्क पर अलग टेबल स्पेस पर रखते हैं और यह ठीक काम करता है।
• हमने संग्रह देखने के लिए 2 फ़ॉर्म बनाए:
  • सामान्य दर्शक जो संग्रह तालिका पर फ़िल्टर के अनुसार संग्रह तालिका को सूचीबद्ध कर सकता है। फ़िल्टर डेटा उपयोगकर्ता प्रपत्र (समय अवधि, उपयोगकर्ता, ...) पर दर्ज कर सकता है। हम प्रत्येक रिकॉर्ड को फ़ील्डनाम/मान के रूप में दिखाते हैं और प्रत्येक परिवर्तन रंग कोडित होता है। उपयोगकर्ता प्रत्येक रिकॉर्ड के लिए सभी संस्करण देख सकते हैं और वे देख सकते हैं कि किसने और कब परिवर्तन किए।
  • चालान दर्शक - यह एक जटिल था, लेकिन हमने ऐसा प्रपत्र बनाया जो चालान को मूल चालान प्रविष्टि प्रपत्र के समान ही दिखाता है, लेकिन कुछ अतिरिक्त बटनों के साथ जो विभिन्न पीढ़ियों को दिखा सकते हैं। इस फॉर्म को बनाने में काफी मेहनत लगी। फॉर्म को कुछ बार इस्तेमाल किया गया और फिर भुला दिया गया क्योंकि वर्तमान वर्कफ़्लो में इसकी आवश्यकता नहीं थी।
• संग्रह रिकॉर्ड बनाने के लिए कोड सिंगल C# क्लास में स्थित है। डेटाबेस में प्रत्येक टेबल पर ट्रिगर्स की कोई आवश्यकता नहीं है।
• प्रदर्शन बहुत अच्छा है। व्यस्त समय में, सिस्टम का उपयोग लगभग 700-800 उपयोगकर्ता करते हैं। यह ASP.Net एप्लिकेशन है। ASP.Net और Oracle दोनों 8Gb RAM के साथ एक दोहरे XEON पर चल रहे हैं।

विपक्ष:

• एकल तालिका संग्रह प्रारूप समाधान की तुलना में पढ़ने में कठिन होता है जहां प्रत्येक डेटा तालिका के लिए एक संग्रह तालिका होती है।
• संग्रह तालिका में गैर-आईडी फ़ील्ड पर खोज कठिन है - हम केवल LIKE का उपयोग कर सकते हैं स्ट्रिंग पर ऑपरेटर।

तो, फिर से, संग्रह पर आवश्यकताओं की जांच करें . यह मामूली काम नहीं है, लेकिन लाभ और उपयोग न्यूनतम हो सकता है।