मैं किन फ़ील्ड कभी संपादित किए जाने के लिए ऑडिट ट्रेल का उपयोग कैसे करूं?

Question

एक परियोजना के लिए जिस पर मैं काम कर रहा हूं, मुझे रिकॉर्ड में किए गए सभी परिवर्तनों का ऑडिट ट्रेल बनाने के लिए कहा गया है। यह पहली बार है जब मुझे ऑडिट ट्रेल बनाना पड़ा, इसलिए मैं इस विषय पर बहुत सारे शोध कर रहा हूं।

एप्लिकेशन PHP/MSSQL में विकसित किया जाएगा, और कम यातायात होगा।

मेरे पढ़ने से, मैंने ऑडिट तालिका रखने और तालिका में बदलावों को रिकॉर्ड करने के लिए ट्रिगर्स का उपयोग करने का काफी निर्णय लिया है।

आवेदन में प्रदर्शन के लिए दो आवश्यकताओं इस प्रकार हैं:

1. एक क्षेत्र में किए गए परिवर्तनों का एक लॉग देखने के लिए सक्षम होना चाहिए (मैं काफी ऐसा करने के तरीके जानते हैं)

2. एप्लिकेशन में रिकॉर्ड देखने पर, देखने में सक्षम रहें, रिकॉर्ड में किसी भी फ़ील्ड के बगल में एक संकेतक जो कभी भी बदला गया है (और संभावित रूप से अंतिम जानकारी की तारीख जैसी अन्य जानकारी)।

आइटम # 2 वह है जो वर्तमान में मुझे दुःख दे रहा है। प्रत्येक फ़ील्ड के लिए एक अलग क्वेरी करने के बिना (या एक बहुत लंबी घोंसला वाली क्वेरी जो निष्पादित करने में आयु लेती है), क्या किसी को ऐसा करने के लिए इष्टतम तरीके के लिए सुझाव हैं? (मैंने तालिका में प्रत्येक फ़ील्ड के लिए एक अतिरिक्त "संशोधित फ्लैग" फ़ील्ड जोड़ने का विचार किया है, जो कि क्षेत्र को कभी भी संपादित किया गया है, लेकिन यह बहुत अधिक ओवरहेड की तरह लगता है।

Answer 1

मैं इलाज करूंगा जितना संभव हो उतना वास्तविक डोमेन जानकारी से अलग लेखा परीक्षा जानकारी

आवश्यकता # 1:।। मुझे लगता है कि आप परिवर्तनों को दर्ज करने के लिए अतिरिक्त लेखा परीक्षा टेबल बना होगा एरिक सुझाव है, एक अच्छा एक है का उपयोग कर लेखा परीक्षा जानकारी बनाने SQL डेटाबेस में ट्रिगर्स। इस प्रकार आपके एप्लिकेशन को ऑडिट तर्क से अवगत नहीं होना चाहिए।

यदि आपका डेटाबेस ट्रिगर्स का समर्थन नहीं करता है, तो शायद आप किसी प्रकार की दृढ़ता या डेटाबेस परत का उपयोग कर रहे हैं। यह इस तरह के तर्क को रखने के लिए एक अच्छी जगह भी होगी, क्योंकि आप सामान्य एप्लिकेशन कोड और ऑडिट कोड के बीच किसी भी निर्भरता को कम करते हैं।

आवश्यकता # 2: संकेतक दिखाने के लिए के रूप में: मैं मेज है कि वास्तविक संग्रहीत करता है में बूलियन क्षेत्र बनाने नहीं होगा। (यह निर्भरता के सभी प्रकार के अपने सामान्य आवेदन कोड और अपने लेखापरीक्षा निशान कोड के बीच अस्तित्व के लिए कारण होगा।)

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

कुछ बड़ा Enterprisy आवेदन है कि मैं बनाए रखने के मोटे तौर पर निम्नलिखित संरचना का उपयोग करता:

• एक परिवर्तन हैडर तालिका किसी तालिका में एक रिकार्ड का एक परिवर्तन के लिए इसी।

फील्ड्स:

changeId, changeTable, changedPrimaryKey, userName, dateTime 

- एक परिवर्तन क्षेत्र तालिका एक क्षेत्र है कि बदल गया है करने के लिए इसी।

फील्ड्स:

changeId, changeField, oldValue, NewValue 

नमूना सामग्री:

हैडर बदलें:

'1', 'BooksTable', '1852860138', 'AdamsD', '2009-07-01 15:30' 

बदलें मद:

'1', 'Title', 'The Hitchhiker's Guide to the Gaxaly', 'The Hitchhiker's Guide to the Galaxy' 
'1', 'Author', 'Duglas Adasm', 'Douglas Adams' 

यह संरचना वांछित संकेतक दिखाने के लिए ऑडिट ट्रेल्स के साथ-साथ आसान पुनर्प्राप्ति दोनों को आसानी से देखने की अनुमति देती है। एक प्रश्न (शीर्षलेख और आइटम तालिका में आंतरिक शामिल) एक ही रूप में दिखाने के लिए सभी जानकारी पुनर्प्राप्त करने के लिए पर्याप्त होगा। (या यहां तक ​​कि एक टेबल जब आपके पास दिखाए गए आईडी की एक सूची है)

Answer 2

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

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

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

फिर जब हम ड्रिल पर एक ही रिकॉर्ड में आते हैं। प्रति फ़ील्ड फिर से एक साधारण ध्वज उपयोगी नहीं है (हालांकि आपका डोमेन, आपकी आवश्यकताओं)। यदि ऐसा है, तो आपका सारांश विचार ठीक है। मेरा अनुमान है कि एक क्षेत्र में परिवर्तन का अनुक्रम, और रिकॉर्ड में समग्र परिवर्तनों का अनुक्रम, और अधिक दिलचस्प है। कर्मचारी ने वेतन वृद्धि की, कर्मचारी स्थानांतरित हो गया, कर्मचारी को पदोन्नत किया गया = तीन अलग-अलग व्यावसायिक कार्यक्रम या एक?

यदि किसी साधारण ध्वज से अधिक कुछ भी आवश्यक है तो मुझे संदेह है कि आपको रिकॉर्ड के लिए पूरे (या हालिया) ऑडिट ट्रेल को वापस करने की आवश्यकता है और यूआई को यह पता लगाने की अनुमति दें कि उसे कैसे पेश किया जाए।

तो, मेरा प्रारंभिक विचार: सारांश रिकॉर्ड का कुछ प्रकार रोलिंग-रखरखाव एक अच्छा विचार की तरह लगता है। यदि आवश्यक पृष्ठभूमि थ्रेड या बैच नौकरियों में बनाए रखा है। हम हर बार पूर्ण लेखापरीक्षा के निशान के बिना व्यापार-उपयोगी होने के लिए तैयार हैं। फिर विस्तृत विश्लेषण के लिए हम कुछ या सभी निशानों को पुनर्प्राप्त करने की अनुमति देते हैं।

Answer 3

व्यक्तिगत रूप से, मैं ट्रैकिंग को सरल बना देता हूं, और रिपोर्टिंग फंकी।

जब भी कोई उपयोगकर्ता एक रिकॉर्ड सम्मिलित करता है, तो आप उस तालिका के लिए लेखा परीक्षा तालिका में एक डालने कर

'I', 'Date', 'User', 'Data column1','Data Column2', etc. 

कि टेबल की संरचना संभालने है समय के साथ (फिर भी नहीं बदलेगा। की राशि datacolumns)

अद्यतन के लिए, बस सम्मिलित

'U', 'Date', 'User', 'Data column1', etc 

सम्मिलित क्या उपयोगकर्ता सिर्फ एक अद्यतन के रूप में प्रवेश किया।

फिर, डालने और अद्यतन के बाद, आप निम्न

'I','May 3 2009','BLT','person005','John','Smith','Marketing' 
'U','May 4 2009','BLT','person005','John','Smith','Accounting' 

तब होगा, यह दिखाने के लिए कि अद्वितीय व्यक्ति के रिकॉर्ड 'person005' एक डालने और एक अद्यतन है, जहां पड़ा है बस एक आसान रिपोर्ट है उनके विभाग को अद्यतन किया गया था।

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