ऑडिट तालिका बनाम टाइप 2 धीरे-धीरे बदलते आयाम

Question

SQL सर्वर 2008+ में, हम एक परिचालन डेटाबेस में "ग्राहक" तालिका में ऐतिहासिक परिवर्तनों की ट्रैकिंग को सक्षम करना चाहते हैं।

यह एक नई टेबल है और हमारा ऐप डेटाबेस पर सभी लेखन को नियंत्रित करता है, इसलिए हमें ट्रिगर जैसे बुराई हैक की आवश्यकता नहीं है। इसके बजाए हम अपनी व्यावसायिक ऑब्जेक्ट परत में परिवर्तन ट्रैकिंग का निर्माण करेंगे, लेकिन हमें उपयोग करने के लिए सही डेटाबेस स्कीमा को समझने की आवश्यकता है।

पंक्तियों की संख्या 100,000 से कम होगी और प्रति रिकॉर्ड में परिवर्तन प्रति वर्ष औसत 1.5 होगा।

वहाँ कम से कम दो तरीके हम इस मॉडलिंग को देखकर किया गया है कर रहे हैं: एक Type 2 Slowly Changing Dimension तालिका के रूप में

1. ग्राहक के वर्तमान संस्करण के लिए CustomersHistory कहा जाता है, कॉलम के साथ EffectiveStartDate के लिए, NULL करने के लिए EffectiveEndDate (सेट), और ChangeReason और ChangedByUsername जैसे ऑडिटिंग कॉलम। फिर हम उस तालिका पर Customers देखेंगे जिसे EffectiveEndDate=NULL पर फ़िल्टर किया गया है। हमारे ऐप के अधिकांश भाग उस दृश्य का उपयोग करके पूछताछ करेंगे, और केवल वे हिस्सों जिन्हें इतिहास-जागरूक होने की आवश्यकता है, अंतर्निहित तालिका से पूछेंगे। प्रदर्शन के लिए, हम दृश्य को पूरा कर सकते हैं और/या EffectiveEndDate = NULL पर फ़िल्टर किए गए इंडेक्स को जोड़ सकते हैं।

2. एक अलग ऑडिट तालिका के साथ। Customer रिकॉर्ड में प्रत्येक परिवर्तन Customer तालिका में और फिर CustomerHistory ऑडिट तालिका में लिखता है।

StackOverflow सवाल की एक त्वरित समीक्षा से, # 2 अधिक लोकप्रिय हो रहा है। लेकिन ऐसा इसलिए है क्योंकि अधिकांश डीबी ऐप्स को विरासत और दुष्ट लेखकों से निपटना पड़ता है?

यह देखते हुए कि हम एक खाली स्लेट से शुरू कर रहे हैं, तो किसी भी दृष्टिकोण के पेशेवर और विपक्ष क्या हैं? आप किसकी सिफारिश करेंगे?

Answer 1

सामान्यतः, एससीडी टाइप- II के साथ समस्या यह है कि, गुणों के मूल्यों में परिवर्तन की औसत संख्या बहुत अधिक है, तो आप बहुत मोटा आयाम तालिका समाप्त करते हैं। यह बढ़ती आयाम तालिका एक बड़ी तथ्य तालिका के साथ जुड़ गई है धीरे-धीरे क्वेरी प्रदर्शन धीमा कर देती है। यह धीमी जहर की तरह है .. शुरुआत में आप प्रभाव नहीं देखते हैं। जब आप इसे महसूस करते हैं, तो बहुत देर हो चुकी है!

अब मैं समझता हूं कि आप EffectiveEndDate = NULL के साथ एक अलग भौतिक दृश्य बनायेंगे और इसका उपयोग आपके अधिकांश जोड़ों में किया जाएगा। इसके अतिरिक्त आपके लिए, डेटा वॉल्यूम तुलनात्मक रूप से कम (100,000) है। प्रति वर्ष केवल 1.5 के औसत परिवर्तन के साथ, मुझे नहीं लगता कि डेटा वॉल्यूम/क्वेरी प्रदर्शन इत्यादि निकट भविष्य में आपकी समस्या होगी।

दूसरे शब्दों में, आपकी तालिका वास्तव में धीरे-धीरे बदलती आयाम (rapidly changing dimension के विपरीत - जहां आपका विकल्प # 2 बेहतर फिट है)। आपके मामले में, मैं विकल्प # 1 पसंद करूंगा।