हमने हाल ही में सीडीसी को भी देखना शुरू किया है। मैं इस विषय का विशेषज्ञ नहीं हूं, लेकिन मुझे लगता है कि मेरे पास आपके सवालों के कुछ जवाब हैं।
अधिकांश भाग के लिए, CDC आपको पूरी तरह से ट्रेस किए जाने योग्य इतिहास के अपने लक्ष्य को प्राप्त करने में मदद करेगा , लेकिन मुझे नहीं लगता कि यह आपको वहां तक पहुंचाएगा।
सबसे पहले:
हम अक्सर डेटाबेस स्कीमा में परिवर्तन करते हैं ... क्या सीडीसी तालिका को नए स्कीमा में अद्यतन करने के लिए एक तंत्र है
और यह वह जगह है जहां मुझे लगता है कि सीडीसी आपको विफल कर देगा। MSDN प्रलेखीकरण अनुभाग "ट्रैकिंग ओवरहेड बदलें समझना" के तहत है कि यह आप के लिए स्कीमा परिवर्तनों को ट्रैक नहीं होगा बहुत स्पष्ट है। उदाहरण के लिए, साथ Alter Table Add Column:
यदि नया ट्रैक ट्रैक की गई तालिका में जोड़ा जाता है, तो स्तंभ के जोड़ को ट्रैक नहीं किया जाता है। केवल नए कॉलम में किए गए अद्यतन और परिवर्तन ट्रैक किए गए हैं।
Drop Column थोड़ा और अधिक जटिल है।
हालाँकि, आपको अपने स्कीमा को बदलने के लिए DB स्क्रिप्ट्स का उपयोग करना चाहिए ताकि आपको यहाँ CDC पर भरोसा न करना पड़े। यह आपको अपने QA और उत्पादन स्कीमा के बीच निरंतरता रखने की अनुमति देता है। और QA में परिवर्तन स्क्रिप्ट द्वारा किया जाना चाहिए ताकि सटीक वही परिवर्तन उत्पाद पर लागू किया जा सके। स्कीमा परिवर्तन को उन लिपियों से बाहर निकालना बहुत कठिन नहीं होना चाहिए। इसका मतलब यह हो सकता है कि आपके इतिहास का "समय" आयाम वास्तविक समय के बजाय संस्करण द्वारा संचालित किया जाएगा, लेकिन अंतिम परिणाम समान होगा।
यदि आपके पास पहले से कोई नहीं है, तो अपने डेटाबेस स्कीमा के संस्करण को ट्रैक करने के लिए एक तालिका बनाएं। और फिर उस डेटाबेस स्कीमा संस्करण तालिका को सीडीसी के अंतर्गत रखें ताकि आप किसी विशेष तालिका के भीतर सूक्ष्म परिवर्तनों के खिलाफ स्कीमा में मैक्रोस्कोपिक परिवर्तनों को संरेखित कर सकें।
मेरी समझ से, आपको अभी भी नए कॉलम में जोड़े गए डेटा को देखना चाहिए, भले ही सीडीसी में स्कीमा परिवर्तन न दिख रहा हो। और टेबल से टेबल तक डेटा माइग्रेशन भी सीडीसी द्वारा उठाया जाना चाहिए।
डेटाबेस स्कीमा को स्थानांतरित करते समय कैप्चर किए गए डेटा से आप कैसे निपटते हैं, इसके लिए कोई सर्वोत्तम अभ्यास हैं?
ऐसा व्यवहार करें जैसे आप एक ऑडिट का इलाज करेंगे। आपको यह समझने की ज़रूरत है कि आप क्या जाँच कर रहे हैं, आप इसकी जाँच क्यों कर रहे हैं, और आपको उस जानकारी को कब तक रखने की आवश्यकता है। स्कोप और रिटेंशन दो सबसे बड़े बुगाबो हैं जब यह इस तरह के कार्य के लिए आता है।
सीडीसी के रिपोर्टिंग उपकरण काफी महत्वपूर्ण हैं, इसलिए आपको परिवर्तनों के संदर्भ को जानना होगा। यह कहना आसान है " सब कुछ ट्रैक करें !" और एक परिणाम के रूप में प्रयोग करने योग्य कुछ भी नहीं के साथ समाप्त होता है। इसी तरह, आप हर परिवर्तन की एक प्रति रख कर अपने डेटाबेस के आकार को दोगुना कर सकते हैं। कई आवेषण और हटाए जाने के साथ एक उच्च मंथन तालिका में, आप खगोलीय वृद्धि के साथ समाप्त करेंगे। यह अपने आप में बुरा नहीं है, लेकिन आपको उस विकास के लिए बजट की आवश्यकता है और आपके द्वारा उत्पन्न किए गए सभी डेटा की जांच करने का एक साधन है।
तो यह आपको यह समझने के लिए वापस करता है कि आपको पूर्ण ट्रेसबिलिटी के लिए क्यों धकेला जा रहा है। उस आवश्यकता के लिए निश्चित रूप से मान्य कारण हैं। लेकिन आप डेटाबेस की अपनी प्रभावी ऑडिटिंग की संरचना तब तक नहीं कर पाएंगे, जब तक आपको पता न हो कि आपको उस आवश्यकता को क्यों पूरा करना चाहिए।