मुझे यकीन नहीं है कि एक "सर्वश्रेष्ठ दृष्टिकोण" है, ध्यान में रखने के लिए बहुत सारे चर हैं, जिसमें आप विकास पथ से कितनी दूर हैं।
कोड-आधारित और डीबी-ट्रिगर ऑडिटिंग समाधान दोनों के माध्यम से होने के बाद, मैंने नीचे कुछ टिप्पणियां सूचीबद्ध की हैं; मुझे आशा है कि आप देख सकते हैं कि आप अभी कहां हैं (विकास के मामले में) इन मुद्दों को प्रभावित कर सकते हैं:
- यदि आपको डेटा बदलने वाले उपयोगकर्ता को मैप करने की आवश्यकता है (जो आप सामान्य रूप से करते हैं) तो डीबी ट्रिगर्स को यह जानकारी किसी भी तरह प्राप्त करने की आवश्यकता होगी। असंभव नहीं है, लेकिन अधिक काम और इस तक पहुंचने के कई तरीके (डीबी उपयोगकर्ता निष्पादन क्वेरी, प्रत्येक तालिका में सामान्य उपयोगकर्ता कॉलम, आदि)
- यदि आप डीबी ट्रिगर का उपयोग करते हैं और आप क्वेरी से लौटाई गई प्रभावित पंक्तियों की संख्या पर भरोसा करते हैं, तो आपके ऑडिट ट्रिगर को इसे बंद करना होगा, या आपके मौजूदा कोड को उनके लिए खाते में संशोधित करना होगा।
- IMHO db ट्रिगर अधिक सुरक्षा प्रदान करते हैं, और ऑडिट ऑटोमेशन के लिए एक आसान रास्ता प्रदान करते हैं, हालांकि वे फुलप्रूफ नहीं हैं, क्योंकि उपयुक्त एक्सेस वाला कोई भी व्यक्ति ट्रिगर्स को अक्षम कर सकता है, डेटा को संशोधित कर सकता है और फिर उन्हें फिर से सक्षम कर सकता है। दूसरे शब्दों में, सुनिश्चित करें कि आपके डीबी सुरक्षा एक्सेस अधिकार कड़े हैं।
- इतिहास के लिए एक ही टेबल होना कोई बुरा तरीका नहीं है, हालांकि अगर आप कई टेबलों के इतिहास का ऑडिट कर रहे हैं, खासकर जब ऑडिट ट्रेल को फिर से बनाने की बात आती है, तो आपको और काम करना होगा (और स्टोर करने के लिए डेटा)। यदि एक ऑडिट टेबल पर कई टेबल लिखने की कोशिश कर रहे हैं तो आपको लॉकिंग मुद्दों पर भी विचार करना होगा।
- प्रत्येक तालिका के लिए एक ऑडिट इतिहास तालिका होना एक अन्य विकल्प है। आपको ऑडिट तालिका में प्रत्येक कॉलम को अशक्त होने के साथ-साथ कार्रवाई की तारीख और समय (सम्मिलित/अद्यतन/हटाएं) और कार्रवाई से जुड़े उपयोगकर्ता को संग्रहीत करने की आवश्यकता है।
- यदि आप सिंगल टेबल विकल्प के साथ जाते हैं, जब तक कि आपके पास इस पर खर्च करने के लिए बहुत समय न हो, केवल अपडेट या डिलीट पर ऑडिट करने की कोशिश करने में बहुत अधिक कल्पना न करें, हालांकि यह सम्मिलित करने से बचने के लिए आकर्षक हो सकता है (क्योंकि अधिकांश ऐप्स इसे अपडेट या डिलीट करने की तुलना में अधिक बार करते हैं), ऑडिट इतिहास को फिर से बनाने में काफी काम लगता है।
- यदि आपके सर्वर या डेटा कई समय-क्षेत्रों में फैले हुए हैं, तो समयरेखा को संग्रहीत और पुनर्निर्माण करने में सक्षम होने के लिए एक उपयुक्त डेटाटाइम प्रकार का उपयोग करने पर विचार करें, यानी यूटीसी में ऑडिट इवेंट की तारीख को स्टोर करें और साथ ही टाइमज़ोन ऑफ़सेट भी शामिल करें।
- ये ऑडिट टेबल बहुत बड़ी हो सकती हैं, इसलिए यदि वे प्रदर्शन को प्रभावित करना शुरू करते हैं तो एक रणनीति बनाएं। विकल्पों में विभिन्न डिस्क पर तालिका विभाजन, संग्रह, आदि शामिल हैं। मूल रूप से इस बारे में अभी सोचें और तब नहीं जब यह एक समस्या बन जाए :)
