संशोधन इतिहास को बनाए रखने के लिए डीबी डिजाइन में सामान्य रणनीतियों क्या हैं? अगर यह सिर्फ एक टेबल था जिसके साथ मैं काम कर रहा था, मुझे लगता है कि यह इतना कठिन नहीं होगा। बस प्रत्येक अद्यतन को तालिका में एक नए रिकॉर्ड के रूप में सहेजें। अंतिम रिकॉर्ड हमेशा नवीनतम संशोधन होगा।डाटाबेस डिज़ाइन: इतिहास को कैसे ट्रैक करें?
लेकिन जब डेटा एकाधिक तालिकाओं में संग्रहीत किया जाता है, तो इसे डिज़ाइन करने का एक अच्छा तरीका क्या है ताकि यह संशोधन को ट्रैक कर सके?
मैं प्रत्येक संस्करण तालिका के लिए अतिरिक्त ऐतिहासिक तालिका रखना पसंद करता हूं। time_from और time_to अतिरिक्त फ़ील्ड के साथ मुख्य तालिका के समान संरचना। पारदर्शी रूप से ट्रिगर्स से भरा हुआ है। नवीनतम पुनरीक्षण सेट के time_to अब तक के भविष्य में सेट है।
निर्दिष्ट पल के लिए राज्य इस तरह क्वेरी के साथ प्राप्त किया जा सकता है:
SELECT * FROM user_history
WHERE time_from >= '2012-02-01' AND time_to <= '2012-02-01'
मेरे लिए, मुख्य तालिका के भीतर इतिहास संग्रहीत आम तौर पर एक अच्छा विचार नहीं है, के रूप में यह जटिल परिस्थितियों की आवश्यकता होती है जब पुन: प्राप्त करने या मौजूदा डेटा में शामिल होने ।
MySQL के binary logging चालू करें और बस इसका उपयोग करें।
मुझे लगता है कि यह प्रश्न पूछताछ इतिहास के बारे में है। – MaxSem
मैं दृष्टिकोण का उपयोग कर रहा हूं, जहां प्रत्येक ऑब्जेक्ट के साथ मैं कम से कम 1 उदाहरण तालिका कहलाता हूं, जहां मैं डेटा को समय के साथ बदलता रहता हूं। आम तौर पर ऐसी सारणी निम्नलिखित अवधारणा का पालन करती हैं:
_HISTORY नाम में प्रत्यय है;start_dt और end_dt, ऑब्जेक्ट इंस्टेंस के जीवनकाल को इंगित करता है;start_dtNOT NULL, end_dtNULL हो सकता है, जो इंगित करता है कि उदाहरण वर्तमान है और इसके समय में सीमित नहीं है;31/Dec-2012 23:59:59 करने के लिए वर्तमान उदाहरण के end_dt सेट और 1/Jan-2013 00:00:00 की start_dt साथ एक नया रिकार्ड डालने की आवश्यकता आप चाहते हैं एक नई कंपनी का नाम 1/Jan-2013 से सक्रिय होने के लिए कहते हैं, भविष्य दिनांकित परिवर्तन सम्मिलित करने के लिए संभव है;revision फ़ील्ड भी जोड़ता हूं, यदि संशोधन को ट्रैक करना आवश्यक है।इस तरह के डिज़ाइन के साथ उचित आरआई बाधाओं के लिए, मेरे पास हमेशा संस्करणों के लिए 2 टेबल होते हैं।
customer (customer_id INTEGER, PRIMARY KEY (customer_id));
customer_history (customer_id INTEGER, start_dt TIMESTAMP, end_dt TIMESTAMP,
name VARCHAR(50), sex CHAR(1), ...,
PRIMARY KEY (customer_id, start_dt));
customer_bank_history (customer_id INTEGER, start_dt TIMESTAMP, end_dt TIMESTAMP,
bank_id INTEGER, iban VARCHAR(34));
अन्य सभी स्थानों मैं customer(customer_id) का उपयोग विदेशी कुंजी बनाने के लिए: कहो, Customer obejct के लिए मैं टेबल के निम्नलिखित सेट है।वास्तविक ग्राहक विवरण पता कर रहा है सरल है:
SELECT c.customer_id, ch.name, ch.sex
FROM customer c
JOIN customer_history ch ON c.customer_id = ch.customer_id
AND now() BETWEEN ch.start_dt AND coalesce(end_dt, now());
मैं ऐसे डिजाइन क्यों पसंद करते हैं:
आशा है कि यह आपकी मदद करेगा।
कठिन हिस्सा "बेस" टेबल का संस्करण नहीं है - आप केवल अलग-अलग संस्करण हैं क्योंकि आप अलगाव में एक ही तालिका करेंगे।
कठिन हिस्सा कनेक्शन उनके बीच ट्रैकिंग कर रहा है।
आप वास्तव में ऐसा करने जा रहे हैं जो विशेष परियोजना की आवश्यकताओं पर निर्भर करता है। यहां sales orders could be "historized" का उदाहरण दिया गया है, लेकिन कई अन्य विविधताएं संभव हैं।
Datadiff। एपीआई संचालित डीबी संशोधन ट्रैकिंग।
पूर्ण प्रकटीकरण:
मैं Datadiff का निर्माण किया। मुझे एक समाधान की आवश्यकता थी जिसने एसएएसएस उत्पाद का समर्थन करने में मदद के लिए मोंगोडीबी में डेटा मॉडल का दृश्य इतिहास प्रदान किया। यह एसक्यूएल डेटाबेस के साथ भी काम करेगा।
आप key:val नोटेशन के साथ मूल क्वेरीिंग का उपयोग कर सकते हैं। i.e id:123
इसलिए मुख्य सारणी में नवीनतम डेटा है। फिर "ऐतिहासिक" तालिकाओं में प्रत्येक संशोधन की प्रतियां होती हैं? क्या यह सामान्यीकरण तोड़ता है? – StackOverflowNewbie
हां, denormalization घटनाओं, यह सादगी के लिए कीमत है (इतिहास राज्य सरल 'INSERT', 'DELETE', मुख्य तालिका पर अद्यतन' से स्वचालित रूप से उत्पन्न होते हैं) और नवीनतम संशोधन का प्रदर्शन (उदाहरण के लिए मुख्य तालिका में डेटा के आधार पर अनुक्रमणिका होती है जबकि इतिहास की तारीख सूचकांक है)। यदि नवीनतम संशोधन के साथ काम करने के लिए मुख्य संशोधन नहीं है, तो यह दृष्टिकोण टूटा सामान्यीकरण से ग्रस्त हो सकता है। – vearutop