django ऑडिट ट्रायल बनाम रिवर्सन

Question

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

मैं उपलब्ध समाधान

1. AuditTrail के लिए ध्यान दिया है - सरल और यही कारण है कि मैं इसे की ओर inclining रहा है, मैं इसे एकल फाइल कोड को समझ सकता हूँ।
2. Reversion - उपयोग करने के लिए काफी आसान लगता है लेकिन यह सुनिश्चित नहीं है कि यदि आवश्यक हो तो इसे संशोधित करना कितना आसान होगा।
3. rcsField मेरी जरूरतों

मैं इनमें से किसी को भी प्रयास नहीं किया है के लिए बहुत ही जटिल और बहुत अधिक हो रहा है, इसलिए मैं कुछ वास्तविक अनुभवों जानना चाहता था और जो एक मैं का उपयोग करना चाहिए। जैसे कौन सा तेजी से कम जगह का उपयोग करता है, विस्तार करने और बनाए रखने में आसान है?

Answer 1

जैसा कि मैंने अपने प्रश्न में कहा है आरसीएफल्ड मेरी आवश्यकताओं के लिए बहुत अधिक प्रतीत होता है, जो आसान है कि मैं अपनी मेज में कोई भी बदलाव स्टोर करना चाहता हूं, और कुछ रिपोर्ट उत्पन्न करने के लिए बाद में उन परिवर्तनों में वापस आ सकता है।

तो मैं AuditTrail और प्रत्यावर्तन प्रत्यावर्तन कई विशेषताएं (जो मैं की जरूरत नहीं है) के साथ एक बेहतर पूर्ण विकसित आवेदन प्रतीत हो रहा है परीक्षण किया है, इसके अलावा जहाँ तक मुझे पता है यह XML या YAML प्रारूप में एक तालिका में डेटा की बचत होती है, जो मुझे लगता है कि

1. एक एकल तालिका
2. में बहुत अधिक डेटा उत्पन्न होगा कि डेटा मैं पहले से ही मौजूद db उपकरणों का उपयोग करने में सक्षम नहीं हो सकता है पढ़ने के लिए।

AuditTrail इस संबंध में जीतता है कि प्रत्येक तालिका के लिए यह एक इसी लेखा परीक्षा तालिका उत्पन्न करता है और इसलिए परिवर्तन आसानी से पता लगाया जा सकता है, प्रति तालिका डेटा कम है और आसानी से हेरफेर किया जा सकता और रिपोर्ट उत्पन्न करने के लिए उपयोगकर्ता।

तो मैं ऑडिट ट्रायल के साथ जा रहा हूं।

Answer 2

मैं आपको उनमें से किसी के साथ वास्तविक अनुभव नहीं दे सकता लेकिन एक अवलोकन करना चाहता हूं।

मैं ऑडिट ट्रायल द्वारा मानता हूं कि आपका मतलब AuditTrail on the Django wiki है। यदि हां, तो मुझे लगता है कि आप के बजाय HistoricalRecords अपनी पुस्तक Pro Django में एक ही लेखक (मार्टी Alchin उर्फ ​​@gulopine) द्वारा विकसित को देखने के लिए चाहता हूँ। यह Django 1.x के साथ बेहतर काम करना चाहिए।

यह दृष्टिकोण है कि मैं आगामी परियोजना पर उपयोग कर रहा हूं, क्योंकि यह आवश्यक रूप से तकनीकी दृष्टिकोण से दूसरों को मारता है, लेकिन क्योंकि यह उस एप्लिकेशन के लिए ऑडिट ट्रेल की "वास्तविक दुनिया" अपेक्षाओं से मेल खाता है।

Answer 3

व्यक्तिगत रूप से मैं डेटाबेस में ऑडिट टेबल बनाना पसंद करता हूं और ट्रिगर्स के माध्यम से पॉप्युलेट करता हूं ताकि क्वेरी विंडो से भी कोई भी प्रश्न सहेजे जा सके। मैं कभी भी ऑडिट समाधान पर विचार नहीं करता जो डेटाबेस में आधारित नहीं है। यह महत्वपूर्ण है क्योंकि जो लोग डेटाबेस में दुर्भावनापूर्ण परिवर्तन कर रहे हैं या धोखाधड़ी कर रहे हैं, वे वेब इंटरफ़ेस के माध्यम से ऐसा नहीं कर सकते हैं, लेकिन बैकएंड पर सीधे ऐसा करने की संभावना नहीं है। इस सामान में से अधिक चीजें बाहरी हैकर्स की तुलना में असंतुष्ट या लापरवाही कर्मचारियों से होती हैं। यदि आप पहले से ही ओआरएम का उपयोग कर रहे हैं, तो आपका डेटा जोखिम में है क्योंकि अनुमतियां एसपी स्तर की बजाय तालिका स्तर पर हैं जहां वे हैं। इसलिए यह और भी महत्वपूर्ण है कि आप जीयूआई से जो कुछ भी नहीं था, उसमें किसी भी संभावित बदलाव को कैप्चर करें। जब भी डेटाबेस में नई टेबल जोड़े जाते हैं तो ऑडिट टेबल बनाने के लिए हमारे पास गतिशील प्रो होती है। चूंकि हमारी लेखापरीक्षा तालिका केवल परिवर्तनों को पॉप्युलेट करती है, न कि पूरे रिकॉर्ड में, हमें फ़ील्ड जोड़े जाने पर हर बार उन्हें बदलने की आवश्यकता नहीं होती है।

साथ ही संभावित समाधानों का मूल्यांकन करते समय, सुनिश्चित करें कि आप एक विशिष्ट परिवर्तन को पूर्ववत करने के लिए डेटा को वापस करना कितना मुश्किल होगा। एक बार आपके पास ऑडिट टेबल हो जाने के बाद, आप पाएंगे कि यह उन सबसे महत्वपूर्ण चीजों में से एक है जिन्हें आप उनसे करना चाहते हैं। यह भी विचार करें कि डाटाबेस स्कीमा में परिवर्तन के रूप में जानकारी को बनाए रखना कितना मुश्किल होगा।

समाधान का चयन करना क्योंकि यह समझना सबसे आसान प्रतीत होता है, आमतौर पर एक अच्छा विचार नहीं है। आवश्यकताओं, सुरक्षा इत्यादि को पूरा करने के बाद यह आपके सेक्शन मानदंडों में से सबसे कम होना चाहिए