बदलावों का रिकॉर्ड रखने के लिए डेटाबेस और टेबल डिजाइन करने का सबसे अच्छा तरीका?

16

मुझे पहले के बदलावों पर नज़र रखने के लिए एक परियोजना पर एक इतिहास सुविधा स्थापित करने की आवश्यकता है।

मान लीजिए कि मेरे पास अभी दो टेबल हैं:

NOTES TABLE (id, userid, submissionid, message)

SUBMISSIONS TABLE (id, name, userid, filepath)

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

इन तालिकाओं में से प्रत्येक में एक स्तंभ स्थापित करने के लिए सबसे अच्छा तरीका क्या होगा जो यह कहेगा कि एक आइटम "पुराना" है। 0 यदि सक्रिय है या 1 हटाए जाने / अदृश्य होने पर।

मैं एक इतिहास ( AUDIT TRAIL) तालिका भी बनाना चाहता हूं, जो idपूर्व राज्य की है, idनए राज्य की है, इन आईडी का संबंध किस तालिका से है?

mysql database-design audit

— श्वार्ज
स्रोत

1

ऑडिट टेबल बनाने के लिए आप डेटाबेस ट्रिगर्स का उपयोग कर सकते हैं ।

— परिजन शाह

5

कृपया देखें

http://www.codeproject.com/Articles/105768/Audit-Trail-Tracing-Data-Changes-in-Database

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

हम पीटीए ब्याज की सभी तालिकाओं में कुछ मानक पीटीए (समय में) कॉलम जोड़कर हमारे पीटीए (प्वाइंट इन टाइम) प्रणाली में बदल जाने पर कौन सी पंक्तियों को ट्रैक कर सकते हैं।

मैं निम्नलिखित सुझाव देता हूं:

DateCreated – the actual date on which the given row was inserted.
DateEffective – the date on which the given row became effective.
DateEnd – the date on which the given row ceased to be effective.
DateReplaced – the date on which the given row was replaced by another row.
OperatorCode – the unique identifier of the person (or system) that created the row.

— हेक्टर
स्रोत

OLTP एप्लिकेशन के लिए 'समाधान नंबर 2: समर्पित डेटा-अनुरेखण तालिका' को लागू करने का सबसे अच्छा तरीका क्या है।

— AA.SC

वर्तमान में मैं जिस कंपनी के लिए काम करता हूं, वह कई स्कीमाओं का उपयोग करती है, विशेष रूप से ऑडिट ट्रेल के लिए। ऑडिट टेबल वास्तव में सॉल्यूशन # 2 का उपयोग करते समय काफी सरल डिजाइन है (जो कि ठीक वही है जो हम यहां काम में उपयोग करते हैं)। अलग-अलग कार्य (इन्वेंटरी टेबल अपडेटेड, ग्राहक जानकारी अपडेट या डिलीट, ग्राहक की ओर प्रदान की गई क्रेडिट आदि) को तोड़ दें और सामान्य कार्यों के आधार पर ऑडिट टेबल का निर्माण करें, जो उपयोगकर्ता सक्षम हैं। क्या यह आपके प्रश्न का उत्तर आपके db के समाधान 2 को लागू करने के संबंध में है, यदि स्पष्ट नहीं है। धन्यवाद!

— हेक्टर

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

— AA.SC

10

आपके डेटा में वर्ज़निंग क्षमताओं को डिज़ाइन करते समय, कई न्यूनतम (मुझे लगता है) आवश्यकताएं होंगी:

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

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

— TommCatt
स्रोत

1

बहुत अच्छे अंक! हालाँकि, मुझे यह समझ में नहीं आता है This means no flag or other indicator showing which is the current version and which are "history.", अगर कोई झंडा या संकेतक नहीं है, तो हम इतिहास संस्करण से वर्तमान संस्करण को कैसे अलग करते हैं? विशेष रूप से आपके तीसरे बिंदु के आधार पर जो आप सुझाव देते हैं कि उन्हें एक ही तालिका में होना चाहिए।

— GMsoF

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

— टॉम्कट