स्वत: सहेजने वाले ड्राफ्ट के लिए सर्वोत्तम अभ्यास?

Question

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

Answer 1

ड्राफ्ट और प्रकाशित लेखों के लिए अलग-अलग तालिकाओं को अनिवार्य रूप से एक-दूसरे के डुप्लीकेट , मैं दोनों के बीच अंतर करने के लिए एक स्टेटस कॉलम के साथ केवल एक टेबल की तरफ झुकता हूं।

Answer 2

मैं विकिपीडिया के रास्ते पर प्रारूपण करता हूं: मैं पहले संस्करण को सहेजता हूं, और सभी संशोधनों को सहेजा जाता है (समय या स्पष्ट उपयोगकर्ता कमांड के आधार पर) अगले संस्करण के रूप में। यानी के बाद। प्रकाशन आप मसौदा ग्राफ को हटा सकते हैं - या नहीं।

यदि आप डेटाबेस में डेटा सहेजते हैं तो मुझे लगता है कि एक ही तालिका का उपयोग करना अच्छा है (आप स्कीमा संघर्ष से बच सकते हैं), और ड्राफ्ट लाइफसाइकिल को ट्रैक करने के लिए संस्करण/स्थिति का उपयोग करें।

Answer 3

इस ईमेल की तुलना में अधिक पर लागू होता है ...

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

आप ओआरएम सत्यापन नियमों को बंद करने के लिए is_draft = 1 का उपयोग करेंगे, मान्यताओं को ट्रिगर करेंगे या अमान्य ऑब्जेक्ट को सहेजने के लिए बाधाओं की जांच करेंगे। हां, आपको शायद अपनी तालिका में नलिका फ़ील्ड की अनुमति देनी होगी।

प्रक्रिया: ऑब्जेक्ट को सहेजने का प्रयास करें। सत्यापन विफल रहता है। set_draft = 1 सेट करें और फिर से सहेजने का प्रयास करें। यह बचाता है स्क्रीन पर कहीं भी "ड्राफ्ट" डालें :)

उपयोगकर्ता आवश्यक जानकारी में भर जाता है। वस्तु को बचाने की कोशिश करें। सत्यापन पास सेट is_draft = 0 है। यह बचाता है

अब, ईमेल और ब्लॉग पोस्ट के संबंध में, आपके सर्वर को इसे भेजने या इसे तब तक पोस्ट करने की कोशिश नहीं करनी चाहिए जब तक उपयोगकर्ता सहेजने/पोस्ट बटन को हिट नहीं करता है, लेकिन यह वास्तव में एक अलग मुद्दा है।

---

पुराने उत्तर

समस्या यह है कि एक मसौदा मान्य नहीं हो सकता है, और वास्तविक तालिका में सहेजा नहीं जा सकता है। उदाहरण के लिए, कहें कि आपकी तालिका मांग करती है कि विषय शून्य नहीं है, लेकिन उपयोगकर्ता ने इसे अभी तक भर नहीं दिया है।

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

छद्म एसक्यूएल:

create table draft 
id int primary key auto increment, 
entity varchar(64) not null comment 'this way you can find all drafts of say type Email', 
contents longblob not null, 
modified timestamp comment 'this way you can sort by newer drafts' 
modified_by int not null foreign key to user.id comment 'this way you can filter by the user\'s drafts' 

आप भी संलग्नक के भंडारण के लिए एक draft_file तालिका विचार कर सकते हैं या मसौदा के लिए फोटो, और व्यक्तिगत रूप से उन्हें का उपयोग कर सकेंगे:

create table draft_file 
id int primary key auto increment, 
draft_id int not null foreign key to draft.id on delete cascade, 
size int not null comment 'bytes', 
mime_type varchar(64) not null, 
file_name varchar(255) not null, 
contents longblob, 
thumbnail blob comment 'this could be an icon for files/documents' 

हां, तो एक उपयोगकर्ता एक ईमेल लिखने शुरू होता है, हो सकता है सिर्फ शरीर में प्रकार, और कुछ अनुलग्नकों कहते हैं। आपका gui ड्राफ्ट को ईमेल सहेजता है, और अनुलग्नक अपलोड करता है, उन्हें ड्राफ्ट_फाइल पर सहेजता है, और मसौदा आईडी देता है, और आपके गुई में प्रदर्शित फ़ाइलों के लिए यूआरएल डाउनलोड करता है।

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

आपके उपयोगकर्ता फ़ील्ड में भरते हैं, और भेजें हिट करते हैं। आपका सर्वर ईमेल तालिका में ईमेल सहेजता है, संलग्नक को ड्राफ्ट_फाइल से ईमेल_टाचमेंट तालिका में कॉपी करता है, और मसौदे को हटा देता है, अधिमानतः लेनदेन के भीतर।

यह आपकी वास्तविक इकाई तालिका की अखंडता को बनाए रखने के दौरान दीर्घकालिक ड्राफ्ट, जीमेल-शैली अनुलग्नक अपलोड की अनुमति देता है।