आपका ऑडिट डेटा सभी के बजाय एक ही स्थान पर प्रति-तालिका संग्रहीत किया जाना चाहिए। आप क्या करेंगे प्रत्येक तालिका के लिए एक ऑडिट तालिका बनाएं जिसे आप ट्रैक करना चाहते हैं, और ऑडिट तालिका में किसी भी डेटा-मैनिपुलेशन ऑपरेशन के लिए ऑडिट तालिका में एक रिकॉर्ड बनाने के लिए ट्रिगर्स बनाएं।
DELETE . को अस्वीकार करना निश्चित रूप से उचित है items . पर संचालन और item_options टेबल - item_active . जैसे फ़्लैग जोड़ें और item_option_active ताकि आप इसके बजाय उन्हें सॉफ्ट-डिलीट कर सकें। यह उन स्थितियों में सामान्य अभ्यास है जहां आप ऐसे चालानों को संग्रहीत करने जैसे काम कर रहे हैं जो अतीत में ऑर्डर किए गए उत्पादों का संदर्भ देते हैं, और ऐतिहासिक रिपोर्टिंग उद्देश्यों के लिए डेटा की आवश्यकता होती है, लेकिन दैनिक उपयोग के लिए नहीं।
आपकी ऑडिट टेबल कुछ ऐसी नहीं हैं जिनका उपयोग आपको पुराने डेटा को संदर्भित करने के लिए करना चाहिए, आपके सामान्य डेटा मॉडल को पुराने डेटा को "छिपाने" का समर्थन करना चाहिए, जहां यह संभावना है कि यह अभी भी उपयोग किया जा रहा है, और डेटा के कई संस्करणों को संग्रहीत करना जो समय के साथ बदल जाएगा।
ऑडिटिंग के लिए, किसी दिए गए रिकॉर्ड को संशोधित करने के लिए अंतिम उपयोगकर्ता के उपयोगकर्ता नाम को संग्रहीत करना भी उपयोगी होता है - जब वेब एप्लिकेशन से उपयोग किया जाता है, तो आप MySQL के USER() का उपयोग नहीं कर सकते। लॉग ऑन करने वाले के बारे में कोई उपयोगी जानकारी प्राप्त करने के लिए कार्य करता है। एक कॉलम जोड़ने और उसे पॉप्युलेट करने का मतलब है कि आप उस जानकारी का उपयोग अपने ऑडिट ट्रिगर में कर सकते हैं।
एनबी: मैं मान लूंगा कि आप सामान्य परिस्थितियों में आइटम आईडी को बदलने की अनुमति नहीं देंगे - जो आपके ऑडिटिंग सिस्टम को और अधिक जटिल बना देगा।
यदि आप अपनी तालिका में सक्रिय फ़्लैग और अंतिम-संशोधित डेटा जोड़ते हैं, तो वे कुछ इस तरह दिखाई देंगे:
आइटम तालिका:
mysql> desc items;
+------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+----------------+
| item_id | int(11) | NO | PRI | NULL | auto_increment |
| item_name | varchar(100) | YES | | NULL | |
| item_description | text | YES | | NULL | |
| item_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
+------------------+--------------+------+-----+---------+----------------+
आइटम विकल्प तालिका:
mysql> desc item_options;
+---------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+----------------+
| option_id | int(11) | NO | PRI | NULL | auto_increment |
| item_id | int(11) | YES | MUL | NULL | |
| option_name | varchar(100) | YES | | NULL | |
| option_price | int(11) | YES | | NULL | |
| option_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
+---------------+--------------+------+-----+---------+----------------+
आपकी ऑडिट तालिका में चार अतिरिक्त जानकारी संग्रहीत करने की आवश्यकता है:
- ऑडिट आईडी - यह आईडी केवल इस . के इतिहास के लिए अद्वितीय है तालिका, यह वैश्विक मान नहीं है
- द्वारा किया गया परिवर्तन - डेटाबेस उपयोगकर्ता जिसने परिवर्तन किया
- तारीख/समय बदलें
- कार्रवाई का प्रकार -
INSERTयाUPDATE(याDELETEअगर आप इसकी अनुमति दे रहे थे)
आपकी ऑडिट टेबल कुछ इस तरह दिखनी चाहिए:
आइटम ऑडिट टेबल:
mysql> desc items_audit;
+------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+----------------+
| audit_id | int(11) | NO | PRI | NULL | auto_increment |
| item_id | int(11) | YES | | NULL | |
| item_name | varchar(100) | YES | | NULL | |
| item_description | text | YES | | NULL | |
| item_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
| change_by | varchar(50) | YES | | NULL | |
| change_date | datetime | YES | | NULL | |
| action | varchar(10) | YES | | NULL | |
+------------------+--------------+------+-----+---------+----------------+
आइटम विकल्प ऑडिट टेबल:
mysql> desc item_options_audit;
+---------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+----------------+
| audit_id | int(11) | NO | PRI | NULL | auto_increment |
| option_id | int(11) | YES | | NULL | |
| item_id | int(11) | YES | | NULL | |
| option_name | varchar(100) | YES | | NULL | |
| option_price | int(11) | YES | | NULL | |
| option_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
| change_by | varchar(50) | YES | | NULL | |
| change_date | datetime | YES | | NULL | |
| action | varchar(10) | YES | | NULL | |
+---------------+--------------+------+-----+---------+----------------+
अपने ऑडिट टेबल पर विदेशी कुंजियों का इस्तेमाल न करें; ऑडिट टेबल की पंक्तियाँ उन रिकॉर्ड्स की चाइल्ड रो नहीं हैं जिनका वे ऑडिट कर रहे हैं, इसलिए विदेशी कुंजियाँ किसी काम की नहीं हैं।
ट्रिगर
एनबी: MySQL बहु-कथन-प्रकार के ट्रिगर का समर्थन नहीं करता है, इसलिए आपको प्रत्येक INSERT के लिए एक की आवश्यकता है , UPDATE और DELETE (यदि लागू हो)।
आपके ट्रिगर्स को बस INSERT . की आवश्यकता है सभी NEW अंकेक्षण तालिका में मान। items . के लिए ट्रिगर परिभाषाएं तालिका हो सकती है:
/* Trigger for INSERT statements on the items table */
CREATE DEFINER=`root`@`localhost` TRIGGER trigger_items_insert_audit
AFTER INSERT ON items
FOR EACH ROW BEGIN
INSERT INTO items_audit (
item_id, item_name, item_description,
item_active, modified_by, change_by,
change_date, action
) VALUES (
NEW.item_id, NEW.item_name, NEW.item_description,
NEW.item_active, NEW.modified_by, USER(),
NOW(), 'INSERT'
);
END;
/* Trigger for UPDATE statements on the items table */
CREATE DEFINER=`root`@`localhost` TRIGGER trigger_items_update_audit
AFTER UPDATE ON items
FOR EACH ROW BEGIN
INSERT INTO items_audit (
item_id, item_name, item_description,
item_active, modified_by, change_by,
change_date, action
) VALUES (
NEW.item_id, NEW.item_name, NEW.item_description,
NEW.item_active, NEW.modified_by, USER(),
NOW(), 'UPDATE'
);
END;
item_options . के लिए समान ट्रिगर बनाएं टेबल।
अपडेट:ई-कॉमर्स में डेटा इतिहास
ऊपर हमने जो ऑडिट किया है, वह आपको किसी भी डेटाबेस तालिका का इतिहास रखने की अनुमति देगा, लेकिन एक डेटा स्टोर बनाता है जो डेटा के उपयोग के लिए उपयुक्त नहीं है जिसे नियमित रूप से एक्सेस करने की आवश्यकता होती है।
ई-कॉमर्स सिस्टम में, प्रयोग करने योग्य . रखते हुए ऐतिहासिक डेटा महत्वपूर्ण है, ताकि आप कुछ स्थितियों में पुराने मूल्यों को प्रस्तुत करते हुए विशेषताओं को बदल सकें।
यह आपके ऑडिटिंग समाधान से पूरी तरह अलग होना चाहिए
इतिहास को संग्रहीत करने का सबसे अच्छा तरीका है प्रत्येक विशेषता . के लिए एक इतिहास तालिका बनाना जिसे ऐतिहासिक रूप से संग्रहीत करने की आवश्यकता है। इस स्टैक ओवरफ्लो प्रश्न में दी गई विशेषता का इतिहास रखने के बारे में कुछ अच्छी जानकारी है ।
आपकी स्थिति में, यदि आप केवल मूल्य और शीर्षक के बारे में चिंतित हैं, तो आप एक prices बनाएंगे तालिका, और एक item_titles मेज़। प्रत्येक के पास item_options . के लिए एक विदेशी कुंजी होगी टेबल या items तालिका (मास्टर टेबल अभी भी वर्तमान मूल्य, या शीर्षक), और इसकी प्रभावी तिथियों के साथ मूल्य या शीर्षक होगा। effective_from को अपडेट करने से बचने के लिए इन तालिकाओं में बारीक (संभवतः स्तंभ-आधारित) अनुमतियां होनी चाहिए रिकॉर्ड डालने के बाद दिनांक और वास्तविक मान।
आपको ऊपर दिए गए ऑडिटिंग समाधान का उपयोग इन तालिकाओं पर भी करना चाहिए।
