8
मैं अपने डेटाबेस के लिए ऑडिट टेबल बना रहा हूं और इसे चुनने की शैली को चुनने की आवश्यकता है। मैं वर्तमान में तीन विकल्पों पर विचार कर रहा हूं, जिनमें से सभी ट्रिगर्स का उपयोग करके पॉप्युलेट किए जाएंगे:ऑडिट तालिका संरचना
- फ़ील्ड आईडी के साथ एक एकल तालिका | टेबल | कॉलम | पंक्ति | old_value | new_value | टाइमस्टैम्प | यूज़र आईडी। यह एक ही स्थान पर सभी तालिकाओं में सभी परिवर्तनों को ट्रैक करेगा और तालिकाओं की संख्या को कम करने का लाभ होगा। यह थोड़ा मुश्किल पूछताछ करता है, लेकिन असंभव नहीं है।
- टेबल कॉलम के बिना # 1 जैसे एकाधिक टेबल। यह प्रत्येक तालिका से परिवर्तन को अपनी खुद की इतिहास तालिका में अलग करेगा।
- एकाधिक टेबल जो ट्रैक करने के लिए मूल तालिकाओं की स्कीमा दर्पण करते हैं। इससे ट्रिगर्स को लिखना बहुत आसान हो जाएगा, अगर कोई विशिष्ट रिकॉर्ड पर वापस लौटना चाहता है तो डेटा को बहाल करना आसान होगा, लेकिन भंडारण की कीमत पर आएगा, हर क्षेत्र के रूप में, भले ही यह नहीं बदला गया हो, तो होगा डुप्लीकेट, संभवतः कई बार हो। साथ ही, यह जानना मुश्किल हो जाएगा कि कौन से फ़ील्ड एक संस्करण से दूसरे संस्करण में बदल गए हैं।
इनमें से प्रत्येक तीन विकल्प सक्षम हैं, और जहां तक मैं कह सकता हूं कि कार्यक्षमता ऐसी नहीं है जो किसी अन्य में असंभव है। तो ऐसा कुछ होना चाहिए जो मैं विचार नहीं कर रहा हूं या कुछ पैटर्न जो अधिक मानक है। यदि इससे कोई फर्क पड़ता है, तो यह समाधान mysql और sql सर्वर दोनों के लिए काम करना चाहिए (हालांकि मैं बाद में कोड के विनिर्देशों को काम कर सकता हूं)।
मैं संख्या 3 का संस्करण लागू करता हूं। SQL सर्वर में, ट्रिगर संशोधित किए गए प्रत्येक कॉलम की पहचान कर सकता है। मैं उस संपूर्ण पंक्ति के साथ स्टोर करता हूं जो संशोधित है + कुछ ऑडिट विशिष्ट कॉलम (ऑडिटटाइटाइम, उपयोगकर्ताइन्फो, आदि)। मैं हैश स्टोर करता हूं, लेकिन एक ऐसा दृश्य बनाता हूं जो हैश को डीकोड करता है और प्रभावित कॉलम सूचीबद्ध करता है। – datagod