ऑडिट लॉगिंग रणनीतियां

Question

मैं अपने आवेदन के भीतर ऑडिट लॉगिंग के लिए सबसे अच्छी विधि पर निर्णय लेने का प्रयास कर रहा हूं। लॉग का मुख्य कारण घटनाओं (परिवर्तन) के अनुक्रम की रिपोर्ट कर रहा है।

मेरे पास ऑब्जेक्ट्स का पदानुक्रम है, मुझे उस पदानुक्रम के किसी भी हिस्से में कुछ बदलाव होने पर रिपोर्ट बनाने की आवश्यकता है, बाद की तारीख में।

मुझे लगता है कि मैं तीन विकल्प हैं:

1. हर तालिका के लिए एक लॉग और इसलिए वस्तुओं तो रिपोर्ट के लिए एक दृश्य बनाने के पदानुक्रम मिलान है।
2. पदानुक्रम को फ़्लैट करें और तालिका को सामान्य बनाएं, रिपोर्टिंग को आसान बनाएं - सरल चयन कथन।
3. एक लॉग टेबल है और प्रत्येक परिवर्तन के लिए रिकॉर्डिंग कठिन है लेकिन परिवर्तनों के लिए अधिक लचीला है।

मैं वर्तमान में विकल्प 1.

Answer 1

की ओर झुकाव रहा हूँ एक ऑडिट लॉग मूल रूप से घटनाओं हुआ, जो इन घटनाओं, और क्या घटनाओं थे प्रदर्शन के एक कालानुक्रमिक सूची है।

मुझे लगता है कि एक फ्लैट दृश्य बेहतर होगा क्योंकि इसे आसानी से आदेश दिया जा सकता है और पूछताछ की जा सकती है। तो मैं आपके विकल्प # 2/# 3 की तरफ झुका रहा हूं।

लेन-देन प्रकार, समय, उपयोगकर्ता आईडी, क्या बदला गया है, और आपके उत्पाद से संबंधित अन्य प्रासंगिक जानकारी जैसे चीजों को शामिल करें।

आप समय के साथ अपने उत्पाद में चीजें भी जोड़ सकते हैं और आपको अपने ऑडिट लॉग मॉड्यूल को लगातार संशोधित करने की आवश्यकता नहीं होगी।

Answer 2

यदि यह ऑडिटिंग उद्देश्यों के लिए है तो मैं एक ही डीबी में तालिका/तालिकाओं की बजाय एक वास्तविक ऐपेंड-केवल माध्यम का उपयोग करूंगा।

आप सुझाव देते हैं कि यह इतिहास के उद्देश्यों के लिए है - इस मामले में मैं आपके आवेदन/डीबी को पुन: स्थापित करूँगा ताकि वास्तविक स्थिति की बजाय वास्तविक घटनाओं को रिकॉर्ड किया जा सके।

Answer 3

मैं (2) और (3) के साथ जाऊंगा: सभी लेखापरीक्षा प्रविष्टियों के लिए एक एकल तालिका बनाएं।

एक फ्लैट दृश्य अच्छा है, बशर्ते अतिरिक्त काम फ़्लैटनिंग प्रदर्शन को प्रभावित न करे।

Answer 4

आप इसके साथ मदद करने के लिए एक एओपी ढांचे को देख सकते हैं। यह आपको किसी भी/सभी विधियों की शुरुआत या अंत में लॉगिंग कार्यक्षमता इंजेक्ट करने की अनुमति देगा। यदि आप इस सड़क पर जाते हैं, तो यह परिभाषित करने में मदद कर सकता है कि लॉग डेटा संग्रहीत करने के लिए क्या अर्थ होगा।

Answer 5

मुझे इस विषय से बात करना है, भले ही यह पुराना हो।

आमतौर पर केवल एक ऑडिट तालिका होती है क्योंकि आप डेटाबेस में लॉकिंग समस्याएं बनाएंगे क्योंकि सबकुछ उस तालिका को हिट करता है। प्रत्येक तालिका के लिए अलग ऑडिट टेबल का प्रयोग करें।

एप्लिकेशन को ऑडिटिंग करने का भी एक बुरा विचार है। लेखापरीक्षा डेटाबेस स्तर पर की जानी चाहिए या आप कुछ जानकारी खोने का जोखिम उठाते हैं। डेटा केवल अधिकांश डेटाबेस में अनुप्रयोगों से नहीं बदलता है; जब आप सभी 10,000,000 में 10% की वृद्धि की आवश्यकता होती है तो कोई भी उपयोगकर्ता इंटरफ़ेस से एक समय में अपने सभी उत्पादों की कीमतों को बदलने वाला नहीं है। लेखापरीक्षा में उन सभी को न केवल सभी परिवर्तनों को पकड़ना चाहिए। यह अधिकांश डेटाबेस में एक ट्रिगर में किया जाना चाहिए (SQL सर्वर 2008 ऑडिटिंग फ़ंक्शन में बनाया गया है)।सबसे खराब संभावित संभावित परिवर्तनों में से कुछ (धोखाधड़ी करने वाले कर्मचारी या डेटा को दुर्भावनापूर्ण रूप से नष्ट करना चाहते हैं) भी आवेदन के अलावा अन्य जगहों से अक्सर होते हैं, खासकर यदि आप उपयोगकर्ताओं के लिए टेबल स्तर तक पहुंच की अनुमति देते हैं (जो आपको किसी भी वित्तीय डेटाबेस या किसी एक में नहीं करना चाहिए व्यक्तिगत जानकारी)। आवेदन से लेखा परीक्षा इसे पकड़ नहीं पाएगी। डेवलपर्स अक्सर भूल जाते हैं कि उनके डेटा की सुरक्षा में, बाहरी स्रोत ही एकमात्र खतरा नहीं हैं।