ड्राफ्ट/लाइव सामग्री सिस्टम डाटाबेस डिजाइन

Question

मैं एक परियोजना पर काम कर रहा है कि सामग्री के ड्राफ्ट/सजीव संस्करणों की आवश्यकता है और इस तरह के नीचे के रूप में एक डिजाइन के बारे में सोचा है

Article 
    ID 
    Creator 
    CreationDate 
    DraftContent(fk to ArticleContent) 
    PublicContent(fk to ArticleContent) 
    IsPendingApproval 

ArticleContent 
    Title 
    Body 

मैं सोच रहा हूँ अगर यह होगा प्रकाशित होने वाले लेख पर विदेशी कुंजी को बदलने के लिए बेहतर है या यदि ड्राफ्ट टेबल से सामग्री को प्रतिलिपि बनाने के लिए बेहतर है तो लाइव तालिका में।

कोई सुझाव?

संपादित करें: दोनों ड्राफ्ट और लाइव संस्करण एक साथ मौजूद हैं हालांकि लाइव संस्करण केवल एक ही है जो जनता के लिए दृश्यमान है। केवल एक ड्राफ्ट और एक लाइव टेबल

इस डिज़ाइन के कारण का एक हिस्सा उपयोगकर्ताओं को उनके लेखों को लाइव होने से पहले अनुमोदित करना है।

अद्यतन:

हम एक मामूली संशोधन के साथ Kieren के समाधान का उपयोग करने का फैसला किया। IsPublished IsLive जैसी वस्तुओं के लिए कॉलम का उपयोग करने के बजाय हमने एक राज्य कॉलम का उपयोग करने का निर्णय लिया। अन्यथा डिजाइन एक ही बना रहा।

Answer 1

ड्राफ्ट लेख है कि लाइव हो जाते हैं और फिर 'प्रकाशित' कर रहे हैं

सामान्य बात लेख मेज पर एक स्थिति/प्रकार ध्वज के लिए हो सकता है - IsLive।

अलग-अलग तालिकाओं का उपयोग करना अनावश्यक और अनावश्यक है; विदेशी कुंजी बदलना या तो ज्यादा समझ में नहीं आता है। लेख को वैध वस्तु के रूप में सोचें, चाहे उसका ड्राफ्ट या लाइव हो। केवल अंतर है, में मामलों में आप केवल लाइव लेख दिखाना चाहते हैं। भविष्य में कुछ मामलों में, आप दोनों को प्रदर्शित करना चाहेंगे।

लेख है कि संपादित किया जा सकता है और शुरू में लाइव

बनने एक लेख दोनों एक जीवित और मसौदा संस्करण होने के मामले में के बाद एक नया मसौदा संस्करण है - सबसे आम पैटर्न एक मास्टर Article इकाई के लिए किया जाएगा/ऑब्जेक्ट, और उसके बाद ArticleVersion कहें। ArticleVersion में IsLive संपत्ति होगी, या इससे भी बेहतर, Article के पास एक संपत्ति होगी, CurrentLiveVersionId। इस तरह एक लाइव और मसौदा संस्करण चारों ओर झूठ बोल सकते हैं, लेकिन वर्तमान लाइव संस्करण प्राप्त करने के लिए CurrentLiveVersionId द्वारा ArticleVersion पर आप आमतौर पर Article में शामिल होंगे।

ArticleVersion तालिका होने के लाभों में यह तथ्य शामिल है कि एक लेख का एक संपूर्ण इतिहास, एक चेंजलॉग संग्रहीत किया जा सकता है, इसलिए यदि आवश्यक हो तो आप पिछले संस्करणों पर वापस जा सकते हैं, या परिवर्तनों की समीक्षा कर सकते हैं। सभी बहुत कम कार्यान्वयन लागत के लिए ..

मुझे बताएं कि क्या मैं इस विधि को स्पष्ट कर सकता हूं।

Answer 2

आपका डिज़ाइन मेरे लिए उपयुक्त दिखता है। एक नया संस्करण लाइव हो जाता है, मैं करूंगा:

1. UPDATEPublicContent कुंजी (पूर्व) मसौदा लेख को इंगित करने के लिए।

2. DELETE पूर्व-प्रकाशित संदर्भ वाले पूर्व-संदर्भित संदर्भ।

3. NULL DraftContent कुंजी या, हमेशा एक मसौदा संस्करण, INSERT एक नया, रिक्त मसौदा ArticleContent में होने और इसे करने के लिए DraftContent प्रमुख मुद्दा के लिए अपने मॉडल कॉल।