प्रत्येक विवरण के साथ सभी डेटा परिवर्तनों को स्टोर करें (जैसे स्टैक ओवरफ्लो)

विकल्प A:संशोधन डेटा रखने के लिए प्रत्येक तालिका की एक प्रति रखें

मान लें कि आपके पास एक साधारण संपर्क तालिका है:

CREATE TABLE contact (
    id INT NOT NULL auto_increment,
    name VARCHAR(255),
    firstname VARCHAR(255),
    lastname VARCHAR(255),
    PRIMARY KEY (id)
)

आप उस तालिका की एक प्रति बनाएंगे और संशोधन डेटा जोड़ेंगे:

CREATE TABLE contact_revisions (
    id INT NOT NULL,
    name VARCHAR(255),
    firstname VARCHAR(255),
    lastname VARCHAR(255),
    revision_id INT auto_increment,
    type ENUM('INSERT', 'UPDATE', 'DELETE') NOT NULL,
    change_time DEFAULT current_timestamp,
    PRIMARY KEY(revision_id)
)

INSERT . का ट्रैक रखें और UPDATE AFTER . का उपयोग करना ट्रिगर। मूल में प्रत्येक नए डेटा संशोधन पर, संशोधन तालिका में नए डेटा की एक प्रति डालें और संशोधन सेट करें type ठीक से।

लॉग करने के लिए DELETE पुनरीक्षण रूप से सुरक्षित आपको इतिहास तालिका में एक नई पंक्ति भी डालनी होगी! इसके लिए आपको BEFORE DELETE . का उपयोग करना चाहिए हटाए जाने से पहले नवीनतम मानों को ट्रिगर और संग्रहीत करें। अन्यथा आपको हर NOT NULL को हटाना होगा इतिहास तालिका में भी बाधा।

इस कार्यान्वयन के संबंध में कुछ महत्वपूर्ण नोट

• इतिहास तालिका के लिए आपको प्रत्येक UNIQUE KEY drop को छोड़ना होगा (यहां:PRIMARY KEY ) संशोधन तालिका से क्योंकि आपके पास प्रत्येक डेटा संशोधन के लिए एक ही कुंजी कई बार होगी।
• जब आप ALTER एक अद्यतन (जैसे सॉफ़्टवेयर अद्यतन) के माध्यम से मूल तालिका में स्कीमा और डेटा, आपको यह सुनिश्चित करना चाहिए कि इतिहास तालिका और उसके डेटा पर भी वही डेटा या स्कीमा सुधार लागू किए गए हैं। अन्यथा रिकॉर्ड सेट के पुराने संशोधन पर वापस लौटने पर आपको परेशानी होगी।
• वास्तविक दुनिया के कार्यान्वयन में आप जानना चाहेंगे कि किस उपयोगकर्ता ने डेटा को संशोधित किया है। उस पुनरीक्षण रूप से सुरक्षित होने के लिए उपयोगकर्ता तालिका से उपयोगकर्ता रिकॉर्ड को कभी भी हटाया नहीं जाना चाहिए। आपको बस खाते को एक ध्वज के साथ अक्षम कर देना चाहिए।
• आमतौर पर, एक एकल उपयोगकर्ता कार्रवाई में एक से अधिक तालिकाएं शामिल होती हैं। वास्तविक दुनिया के कार्यान्वयन में, आपको यह भी ट्रैक करना होगा कि एकाधिक तालिकाओं में कौन से परिवर्तन एकल उपयोगकर्ता लेनदेन से संबंधित हैं और किस क्रम में भी हैं। वास्तविक उपयोग के मामले में आप एक ही लेन-देन के सभी परिवर्तनों को एक साथ, उल्टे क्रम में वापस करना चाहेंगे। इसके लिए एक अतिरिक्त संशोधन तालिका की आवश्यकता होगी जो उपयोगकर्ताओं और लेन-देन पर नज़र रखे और इतिहास तालिकाओं में उन सभी व्यक्तिगत संशोधनों के लिए एक ढीला संबंध रखे।

लाभ:

• पूरी तरह से डेटाबेस में, एप्लिकेशन कोड से स्वतंत्र। (ठीक है, जब उपयोगकर्ता लेन-देन को ट्रैक करना महत्वपूर्ण नहीं है। इसके लिए एकल क्वेरी के दायरे से बाहर कुछ तर्क की आवश्यकता होगी)
• सभी डेटा अपने मूल स्वरूप में हैं, कोई अंतर्निहित प्रकार के रूपांतरण नहीं हैं।
• संशोधन में खोज पर अच्छा प्रदर्शन
• आसान रोलबैक। बस एक साधारण INSERT .. ON DUPLICATE KEY UPDATE .. करें। मूल तालिका पर विवरण, उस संशोधन के डेटा का उपयोग करके जिसे आप वापस रोल करना चाहते हैं।

योग्यता:

• मैन्युअल रूप से लागू करना कठिन है।
• डेटाबेस माइग्रेशन/एप्लिकेशन अपडेट की बात करें तो इसे स्वचालित करना कठिन (लेकिन असंभव नहीं) है।