डेटा संस्करण के लिए अप्रत्याशित आवश्यकता

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



मान लीजिए कि Google इंजीनियर इस संरचना के साथ एक MySQL डेटाबेस का उपयोग करते हैं:

दस्तावेजों
--id
--name
--creator_id

पत्रक
--id
--document_id
--name

पंक्तियों
--number
--sheet_id
--height

कॉलम
--number
--sheet_id
--width

कोशिकाओं
--id
--sheet_id
--color
--content
--row_number
--col_number
--creator_id

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

संरचना आवश्यकताओं

अनिवार्य

• पिछले सेल मूल्यों को बचाने की क्षमता
• एक ऑनलाइन दस्तावेज़ के पिछले संशोधनों को देखने की क्षमता
• पिछले संस्करण में वापस रोल करने की क्षमता
• कुछ मापदंडों में अलग-अलग संस्करण नहीं हो सकते हैं (आईडी, शीट_आईडी)
• प्रयुक्त ओआरएम में कार्यान्वयन

वांछनीय

• डेटा को एक नई संरचना में स्थानांतरित करने, नमूना लेने, बदलने और डेटा जोड़ने के लिए न्यूनतम संभव श्रम लागत
• डिस्क स्थान की बचत
• पुराने संशोधनों को देखते हुए परिवर्तित कोशिकाओं को हाइलाइट करना

कार्यान्वयन

बहुत विचार-विमर्श के बाद, एक "सूत्र" निकाला गया। क्या होगा अगर हम एक अतिरिक्त तालिका बनाते हैं और मुख्य तालिका और नव निर्मित तालिका में मूल्यों के विभिन्न संस्करणों को जोड़ते हैं।

सबसे पहले, हमें संशोधन के साथ एक तालिका चाहिए:

संशोधन
--id
--parent_id
--document_id
--created_date

हम कोशिकाओं की तालिका 2 से वितरित करते हैं, ताकि जानकारी की आवश्यकता न हो, ताकि संस्करण में कोशिकाओं में बने रहे, और कोशिकाओं में -डेटा - उपयोगकर्ता-संशोधित जानकारी। इसके अलावा, cells_data तालिका में हम create_in_revision_id, हटाए गए_in_revision_id फ़ील्ड और परिवर्तन करने वाले उपयोगकर्ता के पहचानकर्ता जोड़ते हैं।

कोशिकाओं
--id
--sheet_id
--row_number
--col_number
--creator_id

cells_data
--cell_id
--color
--content
--data_creator_id
--created_in_revision_id
--deleted_in_revision_id
(cell_id + create_in_revision_id पर प्राथमिक कुंजी)

हमारे डॉक्यूमेंट ऑब्जेक्ट (यदि हम उद्देश्यपूर्ण ढंग से प्रोग्राम करते हैं) में कोड में हम getRevisionCondition method ($ revisionId = false) जोड़ते हैं, जो कि "0_100,300,301 में" create_in_revision_id (0,100,300,301) में "create_in_revision_id" जैसे SQL उपसर्ग को वापस करना चाहिए। यानी वर्तमान संशोधन और निर्माण में उसके सभी भागीदार "(...)" और "नहीं (...)" में शामिल हैं

नमूना

अगला क्वार है, जो इस तरह दिखता था:

select * from cells where row_number=3 and col_number=2 

में बदल जाता है:

 select c.*,cd.* from cells c,cells_data cd where row_number=3 and col_number=2 and id=cell_id and $revisionCondition 

बेशक, इन तालिकाओं के फ़ील्ड नामों को डुप्लिकेट नहीं किया जाना चाहिए।

नया रिकॉर्ड डालें

यहाँ सब कुछ उतना ही सरल है जितना कि सैंपलिंग। जांचें कि क्या संशोधन की समय सीमा समाप्त हो गई है और अंतिम एक ले लो। उदाहरण के लिए, इस तरह:

 $revision=$document->updateRevisionIfExpired() 

सबसे पहले, मुख्य तालिका (कोशिकाओं) में डालें, फिर संस्करण डेटा (cells_data) के साथ तालिका में। Create_in_revision_id फ़ील्ड में, नवीनतम संशोधन की आईडी लिखें।

रिकॉर्ड हटाएं

यहां हम डिस्क स्थान को बचाने की कोशिश करेंगे। यदि, उदाहरण के लिए, हम संशोधन जीवनकाल के रूप में 30 मिनट निर्धारित करते हैं, तो हम वर्तमान संशोधन के साथ हटाए गए रिकॉर्ड के संशोधन की तुलना करते हैं:

• अगर वे मेल खाते हैं - बस डेटाबेस से हटा दें
• यदि संशोधन पहले से ही बदल गया है, तो बस कक्षों के क्षेत्र में ताज़ा संशोधन की आईडी लिखें_डेटा तालिका - delete_in_revision_id

नोड.जे के लिए, यह इस तरह दिखेगा:

 if(cellRevisionId==currentRevision.getId()){ db.online.query("delete from cells_data where cell_id="+cellId+" and created_in_revision_id="+cellRevisionId) }else{ db.online.update('cells_data',{'deleted_in_revision_id':currentRevision.getId()},{'cell_id': cellId, 'created_in_revision_id' : cellRevisionId}) } 

रिकॉर्ड अपडेट करें

डेटा बदलना कुछ हटाने जैसा है। यदि संशोधन नहीं बदला है, तो डेटा केवल अपडेट करता है, यदि वह बदल गया है, तो हटाए गए_in_revision_id फ़ील्ड को अपडेट किया जाता है और एक नया रिकॉर्ड cells_data तालिका में create_in_revision_id में नए संशोधन आईडी के साथ डाला जाता है।

एक निष्कर्ष के बजाय

क्योंकि संस्करण की आवश्यकता वाले अधिकांश टेबल अब एक नई संरचना में अनुवादित हो गए हैं - मैं फायदे और नुकसान को उजागर कर सकता हूं:

गौरव

• सभी चयन और आवेषण (दूसरे शब्दों में, चयन और आवेषण) जितनी जल्दी हो सके और बिना किसी जटिलताओं के फिर से तैयार किए गए थे
• जो कुछ भी आवश्यक है और लगभग सब कुछ वांछित है

कमियों

• हटाना, रिकॉर्ड को अपडेट करना अभी भी थोड़ा बहुत कसकर घाव हो जाता है और एक अधिक स्वचालित स्क्रिप्ट को चोट नहीं पहुंचेगी
• शायद आपको प्रश्नों के साथ कुछ करने की आवश्यकता है जैसे (...) और (...) में नहीं, क्योंकि वे दस्तावेज़ के सभी संशोधनों को सूचीबद्ध करते हैं