2011-12-15 7 views
7

मैं एक डेटाबेस में एक ब्लॉग पोस्ट स्टोर करना चाहता हूँ। मैंने सोचा कि उस डेटा के विभिन्न संस्करणों के लिए अच्छा होगा, वर्जन नियंत्रण जैसे पाठ फ़ाइलों के लिए।संस्करण-नियंत्रित, डेटाबेस डेटा को संग्रहीत करने के मानक/अनुशंसित तरीके क्या हैं?

तो, मुझे लगता है कि यह एक तालिका में एक पंक्ति की तरह काम कर रहा है, जिसमें संस्करण नियंत्रण था। तो, उदाहरण के लिए, आप उस पंक्ति का नवीनतम संस्करण, या पिछले संस्करण को पुनर्प्राप्त कर सकते हैं। आप उस पंक्ति से भी शाखा बना सकते हैं।

क्या ऐसा कुछ भी मौजूद है?

संभवतः उपयोगी जानकारी: मैं वर्तमान में पाइथन, Django & MySQL का उपयोग कर रहा हूं। मैं MongoDB

स्पष्टता/अधिक संदर्भ के लिए संपादित करें: मैं डेटाबेस की तुलना में पंक्तियों के "संस्करण नियंत्रण" की दिशा में अधिक समाधान के लिए एक समाधान की तलाश में हूं; मैं पूरे डेटाबेस को ब्रांच करने में बहुत दिलचस्पी नहीं रखता हूं। उदाहरण के लिए, मैं 1/1/2011 और 1/1/2010 (ब्लॉग स्विच किए बिना) ब्लॉग पोस्ट की सामग्री से पूछताछ कर पाऊंगा।

+0

क्या आपने गिट की तरह वर्जन कंट्रोल सिस्टम का उपयोग करने पर विचार किया है? ऐसे समाधान के पेशेवरों और विपक्ष को देखना दिलचस्प होगा। – milan

+0

@ मिलन - जब से गिट संस्करण डेटाबेस ** रिकॉर्ड **? –

+0

प्रश्न * कोई * डेटाबेस रिकॉर्ड नहीं कहता है, यह ब्लॉग पोस्ट कहता है, जो ज्यादातर टेक्स्ट हैं, तो क्यों नहीं? – milan

उत्तर

2

सबसे पहले, मुझे कहना होगा कि यह एक दिलचस्प सवाल है।

काम की मेरी लाइन में, मुझे विभिन्न उपयोगकर्ता इनपुट के संस्करणों को सहेजना है। जिस तरह से मैं इसे करता हूं, और हर तरह से मैं वास्तव में नहीं जानता कि यह सही तरीका है या नहीं, निम्नलिखित है:

मेरे पास master तालिका और revisions तालिका है। मैंने उदाहरण के लिए केवल इन 2 नामों को चुना है।

क्या मास्टर करता भंडार निम्नलिखित जानकारी है:

  • आईडी:

    • आईडी (autoincrement)
    • version_id (int)

    क्या revisions दुकान पीछा कर रहा है

  • master_id
  • version_id दर्ज की गई संस्था के बारे में प्रासंगिक डेटा की
  • बाकी (दिनांक, आदि)

मैं इस तरह से क्या हासिल है कि मैं एक आईडी हो गया था, के एक ब्लॉग पोस्ट का कहना है कि करते हैं। अगर कोई पोस्ट संपादित करता है, तो मैं उस जानकारी को revisions तालिका में संग्रहीत करूंगा। ट्रिगर्स के माध्यम से मैं revisions तालिका में वृद्धि कर रहा हूं। उसके बाद मैं नवीनतम version_id नंबर के साथ master तालिका अद्यतन करता हूं। इस तरह मुझे MAX() निष्पादित करने की आवश्यकता नहीं है जब मैं देखना चाहता हूं कि नवीनतम संस्करण क्या है।

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

3

संस्करण नियंत्रण एक जटिल विषय है; इसे सही करना वास्तव में चुनौतीपूर्ण है जो अनिवार्य रूप से भी का उपयोग कर रहा है। गिट कठिन हो सकता है। मैं एक पूर्ण उड़ा संस्करण नियंत्रण प्रणाली नहीं लिखना चाहता।

BlogPost { 
    "_id": ObjectId("..."), 
    "slug" : "how-to-version-my-posts", 
    "author" : "cammil", 
    "published" : date, 
    "lastModified" : date, 
    "publicVersion" : 32, 
    "draftVersion" : 34, 
    "teaserText" : "lorem ipsum dolor sit amet..." 
} 

BlogPostBody { 
    "_id" : ObjectId("..."), 
    "Version" : 32, 
    "Text" : "lorem ipsum dolor sit amet..." 
} 

तो विचार यहाँ प्रत्येक संस्करण अलग से स्टोर करने के लिए है और मौजूदा सार्वजनिक संस्करण के लिए एक सूचक और संपादकों के लिए वर्तमान संस्करण:

सरल आवश्यकताओं के लिए, इस संरचना, छद्म MongoDB/JSON में विचार , ब्लॉगर्स, आदि

मेरा जवाब थोड़ा मोंगो डीबी केंद्रित है (क्योंकि मैंने घर के उपयोग के लिए एक मोंगोडीबी आधारित ब्लॉग इंजन बनाया है), लेकिन इसे किसी भी स्टोरेज सिस्टम के लिए समान रूप से काम करना चाहिए।

लाभ:

  • नहीं जो वांछनीय नहीं हो सकता है
  • संस्करण संख्याओं को last edited संबंध स्थापित नहीं करता है या तो सार्वजनिक या निजी पदों के लिए संस्करण संख्या की MAX प्रश्नों करने की ज़रूरत,
  • संस्करण भी अनुमति देता है यदि कोई निश्चित संस्करण पहले ही प्रकाशित हो चुका है
  • पूरे लेख को लाने के लिए टीज़र w/o प्राप्त कर सकता है

नुकसान:

  • प्रतियां पूरे पाठ हर बार। मुझे लगता है कि पाठ डेटा के लिए एक वास्तविक चिंता नहीं है (1 जीबी टाइप करने का प्रयास करें ...)। हालांकि, बड़ी ब्लॉगिंग साइटों के लिए एक समस्या होगी। कमी: डिफ्लेट, डेल्टा-संपीड़न का उपयोग कर टेक्स्ट संपीड़ित करें।
  • अद्यतन पर दो वस्तुओं को अद्यतन करने के
2

OffScale DataGrove संस्करण आप पूरे डीबी करने की अनुमति देता जरूरत।

यह डीबी के साथ होने वाले सभी परिवर्तनों को ट्रैक करता है और आप संस्करणों को टैग कर सकते हैं और उनके बीच आगे और पीछे स्विच कर सकते हैं। डेटाग्राव इस तथ्य में अद्वितीय है कि यह पूरे डीबी - स्कीमा और डेटा का संस्करण है।

अपने उदाहरण में - बस उस पंक्ति/डेटा को जोड़ें जिसे आप डीबी करना चाहते हैं और एक संस्करण टैग करें। आप हमेशा उस संस्करण पर वापस जा सकते हैं और यहां से शाखा भी कर सकते हैं।

+1

आपके विवरण से, व्यक्तिगत पंक्तियों की तुलना में डेटाग्राव पूरे डेटाबेस के लिए ब्रांचिंग की ओर अधिक उन्मुख प्रतीत होता है। (संपादन देखें) – cammil

संबंधित मुद्दे

 संबंधित मुद्दे