हम वर्तमान में एक वेब एप्लिकेशन कर रहे हैं जो कार्यक्षमता में से एक है उपयोगकर्ता द्वारा घटनाक्रम बनाना। उन घटनाओं को बाद में उपयोगकर्ता या व्यवस्थापक द्वारा हटाया जा सकता है। हालांकि क्लाइंट की आवश्यकता है कि ईवेंट वास्तव में डेटाबेस से भौतिक रूप से हटाया नहीं गया है, लेकिन हटाए गए के रूप में चिह्नित किया गया है। उपयोगकर्ता को केवल गैर-हटाए गए ईवेंट देखना चाहिए, लेकिन प्रशासक हटाए गए लोगों के माध्यम से ब्राउज़ करने में सक्षम होना चाहिए। यह वास्तव में कार्यक्षमता है।डेटाबेस में संग्रह संग्रह। शायद कुछ पैटर्न?
अब मैं सुझाव दिया है कि हम बस एक और अतिरिक्त स्तंभ "स्थिति" कहा जाता है, जो मान्य मान की जोड़ी के लिए होता है जोड़ना चाहिए: सक्रिय और नष्ट। इस तरह हम सामान्य (सक्रिय) और हटाई गई घटनाओं के बीच अंतर कर सकते हैं और वास्तव में सरल प्रश्न बना सकते हैं (स्थिति * से चुनें जहां स्थिति = 'सक्रिय')। हालांकि मेरे सहयोगी असहमत थे। उन्होंने बताया कि परवाह किए बिना तथ्य अभी सक्रिय घटनाओं और हटाए गए ईवेंट में एक ही जानकारी साझा की एक भावी आवश्यकताओं में (इस प्रकार वे एक ही तालिका में संग्रहीत किया जा सकता है) मेरे परिवर्तन और उदाहरण के लिए ग्राहक को नष्ट कर दिया घटना के बारे में कुछ अतिरिक्त जानकारी स्टोर करने के लिए की आवश्यकता होगी (हटाने की तारीख की तरह, जिसने इसे हटा दिया, उसने ऐसा क्यों किया - टिप्पणी की तरह)। उन्होंने कहा कि भविष्य में उन आवश्यकताओं को पूरा करने के लिए हमें EVENTS तालिका में अतिरिक्त कॉलम जोड़ना होगा जो हटाए गए ईवेंट के लिए विशिष्ट डेटा धारण करेगा, न कि सक्रिय घटनाओं के लिए। उन्होंने एक समाधान का प्रस्ताव दिया, जहां अतिरिक्त तालिका बनाई गई है (जैसे DELETED_EVENTS) EVENTS तालिका के समान स्कीमा के साथ। प्रत्येक हटाए गए ईवेंट को EVENTS तालिका से भौतिक हटा दिया जाएगा और DELETED_EVENTS तालिका में ले जाया जाएगा।
मैं दृढ़ता से अपने विचार से सहमत नहीं। न केवल यह SQL क्वेरी को अधिक जटिल और कम कुशल बना देगा बल्कि यह पूरी तरह से यागनी के खिलाफ है। मैं उनके साथ भी असहमत हूं कि अगर मेरा विचार भविष्य में बदलती है, तो मेरे विचार हमें ईवेंट तालिका में अतिरिक्त (नामुमकिन) कॉलम बनाने के लिए तैयार करेंगे। मेरी परिदृश्य में मैं बस DELETED_EVENTS_DATA जैसे नए तालिका बनाने के लिए (है कि उन अतिरिक्त, संग्रह डेटा रखने के हैं) और घटनाओं तालिका में संदर्भ कुंजी जोड़ने एक के बाद एक EVETNS और DELETED_EVENTS_DATA तालिकाओं के बीच संबंध को बनाए रखने के लिए होगा।
फिर भी मैं इस तथ्य है जो आमतौर पर सॉफ्टवेयर और डेटाबेस डिजाइन पर समान विचार से सहमत दो डेवलपर्स कैसे इस आवश्यकताओं एक डेटाबेस स्तर में तैयार किया जाना चाहिए के बारे में तो बिल्कुल भिन्न राय है हो सकता है कि द्वारा संघर्ष किया था। मैंने सोचा कि हम दोनों गलत दिशा में जा रहे हैं और एक और (तीसरा) समाधान है? या फिर सिर्फ एक विकल्प हैं? आप इस तरह की आवश्यकताओं को कैसे डिजाइन करते हैं? क्या यह सही तरीके से करने के तरीके पर कोई पैटर्न या दिशानिर्देश हैं? किसी भी मदद की गहराई से सराहना की जाएगी
आप इसे एक समुदाय विकी के रूप में फ़्लैग करने पर विचार कर सकते हैं - मुझे यकीन नहीं है कि आपको एक सही उत्तरदायी उत्तर मिलेगा। – Mayo
यह एक अच्छा सवाल है और मैं दिखाए गए कुछ उत्तरों को देखने की उम्मीद कर रहा हूं। DELETED_EVENT तालिका में प्रतिलिपि करते समय आपकी तालिका से पंक्तियों को निकालने से आपको कुछ समस्याएं हो सकती हैं यदि आपके ईवेंट तालिका के लिए कोई संदर्भ हैं जो आपको ऐतिहासिक उद्देश्यों के लिए रखने की आवश्यकता है।आप या तो खतरनाक विदेशी कुंजी, या विदेशी कुंजी के साथ समाप्त हो जाएंगे जिसमें आप दोनों टेबलों के साथ संभावित रूप से शामिल हो सकते हैं। यह सुंदर नहीं लगता है। – rayd09
मेरा जवाब उत्तर देने से क्यों हटा दिया गया था ?? – anthonyv