अनुक्रमिक id का उपयोग करना आसान होगा क्योंकि यह शायद (?) प्राथमिक कुंजी है और इस प्रकार अनुक्रमित और उपयोग करने में तेज़ है। यह देखते हुए कि आपके पास user_id है , आप अंतिम और पूर्व के संपादनों पर शीघ्रता से दावा कर सकते हैं।
timestamp का उपयोग करना भी लागू है, लेकिन यह एक लंबी प्रविष्टि होने की संभावना है, और हम नहीं जानते कि क्या यह बिल्कुल अनुक्रमित है, साथ ही टकराव की संभावना भी है। आपने ठीक ही कहा है कि सिस्टम की घड़ियां बदल सकती हैं... जबकि अनुक्रमिक id नहीं कर सकता।
आपके अपडेट को देखते हुए:
चूंकि यह देखना मुश्किल है कि आपकी सटीक आवश्यकताएं क्या हैं, इसलिए मैंने इसे इस बात के प्रमाण के रूप में शामिल किया है कि 200K+ जटिल दस्तावेज़ों और लाखों संशोधनों के लिए किसी विशेष परियोजना की क्या आवश्यकता है।
60 से अधिक पूर्णकालिक शोधकर्ताओं की एक आंतरिक टीम के लिए मेरे अपने अनुभव (एक पूरी तरह से श्रव्य दस्तावेज़/प्रोफाइलिंग प्रणाली का निर्माण) से। हमने एक id . दोनों का उपयोग किया और कई अन्य फ़ील्ड (timestamp . सहित) ) ऑडिट-ट्रेलिंग और पूर्ण संस्करण प्रदान करने के लिए।
हमारे द्वारा बनाई गई प्रणाली में प्रत्येक प्रोफ़ाइल के लिए 200 से अधिक फ़ील्ड हैं और इस प्रकार दस्तावेज़ का संस्करण बनाना हर एक के लिए बदले गए टेक्स्ट/सामग्री के ब्लॉक को संग्रहीत करने से कहीं अधिक जटिल था; फिर भी, प्रत्येक प्रोफ़ाइल को एक दस्तावेज़ के रूप में एक पीडीएफ या अन्य प्रारूप के रूप में संपादित, स्वीकृत, अस्वीकार, रोल-बैक, प्रकाशित और यहां तक कि निर्यात किया जा सकता है।
हमने जो किया (काफी रणनीति/योजना के बाद) प्रोफ़ाइल के अनुक्रमिक संस्करणों को संग्रहीत करना था, लेकिन वे कुंजी मुख्य रूप से थे एक id . पर फ़ील्ड ।
टाइमस्टैम्प
टाइमस्टैम्प को द्वितीयक जांच के रूप में भी कैप्चर किया गया था और हमने क्रॉन स्क्रिप्ट के उपयोग के माध्यम से सिस्टम घड़ियों को सटीक (सर्वर के समूह के बीच) रखना सुनिश्चित किया, जो नियमित रूप से समय-संरेखण की जांच करते थे और जहां आवश्यक हो उन्हें सही करते थे। हमने Ntpd का भी इस्तेमाल किया घड़ी के बहाव को रोकने के लिए।
अन्य कैप्चर किया गया डेटा
प्रत्येक संपादन के लिए कैप्चर किया गया अन्य डेटा भी शामिल है (लेकिन इन्हीं तक सीमित नहीं):
User_id
User_group
Action
Approval_id
ऐसी अन्य तालिकाएँ भी थीं जो आंतरिक आवश्यकताओं को पूरा करती थीं (दस्तावेजों के लिए स्वचालित रूप से उत्पन्न एनोटेशन सहित) - क्योंकि कुछ प्रोफ़ाइल संपादन बॉट्स (एनईआर/मशीन लर्निंग/एआई का उपयोग करके निर्मित) के डेटा का उपयोग करके किया गया था, लेकिन अनुमोदन के साथ एक की आवश्यकता थी संपादन/अपडेट प्रकाशित होने से पहले टीम।
सभी उपयोगकर्ता कार्रवाइयों का एक एक्शन लॉग भी रखा गया था, ताकि ऑडिट की स्थिति में, कोई व्यक्ति व्यक्तिगत उपयोगकर्ता के कार्यों को देख सके - भले ही उनके पास इस तरह की कार्रवाई करने की अनुमति न हो, फिर भी यह लॉग किया गया था। ।
माइग्रेशन के संबंध में, मैं इसे एक बड़ी समस्या के रूप में नहीं देखता, क्योंकि आप डेटा को स्थानांतरित/डंपिंग/स्थानांतरित करने में आईडी अनुक्रमों को आसानी से संरक्षित कर सकते हैं। शायद एकमात्र मुद्दा यह है कि यदि आपको डेटासेट मर्ज करने की आवश्यकता है। आप उस घटना में हमेशा एक माइग्रेशन स्क्रिप्ट लिख सकते हैं - इसलिए व्यक्तिगत दृष्टिकोण से मुझे लगता है कि नुकसान कुछ हद तक कम हो गया है।
डेटा एक्सप्लोरर (जो उचित रूप से परिष्कृत है) के लिए स्टैक ओवरफ़्लो तालिका संरचनाओं को देखने लायक हो सकता है। आप यहाँ तालिका संरचना देख सकते हैं:https://data.stackexchange.com/stackoverflow/query /नया , जो मेटा पर एक प्रश्न से आता है:SO कैसे स्टोर करता है संशोधन?
एक संशोधन प्रणाली के रूप में, SO अच्छी तरह से काम करता है और मार्कडाउन/संशोधन कार्यक्षमता शायद लेने के लिए एक अच्छा उदाहरण है।
