रिकॉर्ड स्थिति कैसे संग्रहीत करें (जैसे लंबित, पूर्ण, ड्राफ्ट, रद्द…)

Question

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

मेरे पास एक सरल ब्लॉग अनुप्रयोग है और प्रत्येक पोस्ट में एक स्थिति है: प्रकाशित, मसौदा या लंबित।

जिस तरह से मैं इसे देखता हूं, डेटाबेस में इसे मॉडल करने के 2 तरीके हैं।

1. पोस्ट टेबल में एक टेक्स्ट फील्ड होता है जिसमें स्टेटस टेक्स्ट शामिल होता है।
2. पोस्ट टेबल में एक स्टेटस फील्ड होता है जिसमें पोस्टस्टैटस टेबल में एक रिकॉर्ड की आईडी होती है

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

क्या कोई भी प्रत्येक के फायदे / नुकसान बता सकता है?

चीयर्स!

इस पर मेरा प्रारंभिक विकल्प यह है कि किसी अन्य तालिका का उपयोग करना बेहतर है और स्थिति को सामान्य बनाने के लिए बेहतर है और मुझे हमेशा सिखाया गया है कि सामान्यीकरण डेटाबेस के लिए अच्छा है

Comments

इसके अलावा dba.stackexchange.com/q/11631/630

— gbn

"किसी भी समय" से आपका क्या मतलब है? क्या इसका मतलब उपयोगकर्ता गतिविधि का हिस्सा है, या सॉफ़्टवेयर रिलीज़ चक्र का हिस्सा है?

— केविन क्लाइन

दोनों, जिन मामलों में यहाँ वर्णित किसी भी दृष्टिकोण का सबसे अच्छा उपयोग किया गया है। इसलिए यदि उपयोगकर्ता नए स्टेटस को जोड़ने में सक्षम हैं, या यदि नए लोगों को प्रोजेक्ट में बाद के बिंदु पर जोड़ा जाता है

— 9

डेटाबेस में पाठ को संग्रहीत करना एक अच्छा विकृतीकरण हो सकता है। मुझे लगता है कि यह सटीक विवरणों पर निर्भर हो सकता है। उदाहरण के लिए, आपका संगठन कितनी बार अपनी प्रक्रियाओं को बदलता है (संभावित स्थिति परिवर्तन के लिए अग्रणी)?

— Jaydee

यदि उपयोगकर्ता नए स्टेटस जोड़ने में सक्षम हैं, तो यह पूरी तरह से एक और बात है। आप शायद स्थिति के साथ बनाने वाले उपयोगकर्ता आदि को रिकॉर्ड करना चाहेंगे और निश्चित रूप से किसी अन्य तालिका की आवश्यकता होगी।

— केविन क्लाइन

Answer 1

एक अन्य तालिका में एक सूचकांक के रूप में स्थिति को संग्रहीत करना एक अनावश्यक जटिलता है। पढ़ने योग्य तरीके से सीधे तालिका में स्थिति को संग्रहीत करें। एप्लिकेशन कोड में स्थिरांक या एक गणना प्रकार का उपयोग करें। यह सरल एप्लिकेशन कोड और डेटा लेयर की डीबगिंग के परिणामस्वरूप होगा।

यह डेटा को निरूपित नहीं करता है, यह केवल प्रतिनिधित्व को बदलता है। यदि डेटाबेस सीधे एन्यूमरेशन का समर्थन करता है, तो इसका उपयोग करें। अन्यथा स्तंभ मानों को प्रतिबंधित करने के लिए एक बाधा का उपयोग करें। आप या तो एक बाधा के रूप में जा रहे हैं: या तो स्तंभ मानों पर एक सीधा बाधा, या एक विदेशी कुंजी बाधा।

हां, आपको अलग-अलग उपयोगकर्ताओं को अलग-अलग स्थिति प्रस्तुत करनी पड़ सकती है। यह एक प्रस्तुति समस्या है, जिसे प्रस्तुति परत में हल किया जाना है, न कि दृढ़ता परत पर।

Comments

+1, db में स्टेटस की सूची को बनाए रखने के लिए एक विशिष्ट आवश्यकता को छोड़कर , यह आम तौर पर इसे करने का सबसे सरल, कम से कम जटिल तरीका है।

— ग्रैंडमास्टरबी

यह ठीक है, जब तक कि आप स्टेटस आर्किटेक्चर बदलना या उत्परिवर्तन तारीखों को जमा करना शुरू नहीं करते हैं

— LastTribunal

Answer 2

स्टेटस टेक्स्ट को स्टोर करना IMO एक अच्छा विचार नहीं है, क्योंकि कोई यह तय कर सकता है कि इसके बजाय "पूर्ण" को "समाप्त" कहा जाना चाहिए और फिर आपको अपने डेटाबेस को अपडेट करना होगा, प्रोग्राम के माध्यम से देखें यदि किसी ने टेक्स्ट को हार्डकोड किया है आदि।

मैंने कई कार्यक्रमों में देखा है कि या तो एक संख्यात्मक कोड है (1 = नया, 2 = मसौदा, सत्यापन में 3 =, 4 = पूर्ण, 99 = रद्द) या एक लघु अल्फ़ान्यूमेरिकल कोड ("नया", "DRA", "INV "," COM "," CAN ")। बाद में कोड बनाता है (प्रोग्राम या डेटाबेस में) अधिक मानव-पठनीय, जो आमतौर पर एक अच्छी बात है। दूसरी ओर, संख्यात्मक कोड उदाहरण के लिए, "तुलना में" या "छोटे" से अधिक करना आसान बनाते हैं

select * from myrecords where status < Status.Complete;

Comments

कुछ बेवकूफ आईडी को हार्डकोर भी कर सकते हैं।

— मोरों

आईडी का एक अन्य लाभ आपको स्थानीयकरण प्रदान करने की आवश्यकता है। संसाधन स्ट्रिंग और प्रदर्शन देखने के लिए आप अपनी आईडी का उपयोग कर सकते हैं। हार्ड कोडित तार के साथ यह संभव नहीं है

— आर्मिटेज

मुझे नहीं लगता कि "तुलना में अधिक" या "तुलना में छोटा" का उपयोग करते हुए स्थितियां आपके द्वारा दिखाए गए एक अच्छा विचार है। यह इस तरह के उदाहरण के रूप में सरल अनुप्रयोगों के लिए काम कर सकता है, लेकिन अधिक जटिल ऐप्स के लिए अच्छा नहीं है (हालांकि यह सुनिश्चित करें कि आपके बारे में पता है)

— वेगास

@armitage: स्ट्रिंग्स का उपयोग करके लुकअप करना पूरी तरह संभव है। संसाधन नाम तार हैं:status.draft=Draught

— केविन क्लाइन

veganista: यकीन है, तुलना से अधिक / छोटे के साथ कठिनाइयाँ हो सकती हैं, लेकिन मैंने बड़े, जटिल सिस्टम देखे हैं जो ऐसा करते हैं और रहते हैं।

— user281377

Answer 3

संबंधपरक डेटाबेस के तीन नियम:

1. सामान्य
2. सामान्य
3. सामान्य

तो आपका सवाल खुद ही जवाब दे देता है। अपनी स्वयं की तालिका के अंदर स्थिति रखें और अपने आईडी के रूप में GUID / UUID का उपयोग करें । अनुक्रमित GUIDS बहुत तेज़ हैं, और संख्याओं को बढ़ाने के लिए आंतरिक समस्याओं को ठीक करते हैं। एक आईडी के साथ आप शांत चीजों को कर सकते हैं जैसे आईडी का उपयोग करके सभी पूर्ण पदों के लिए डीबी से पूछें, और क्योंकि आप रिलेशनल डीबी प्रतिमान के भीतर काम कर रहे हैं, यह बहुत तेज़ है। यदि आपके पास सिर्फ एक क्षेत्र है, तो DB को हर एक पंक्ति में लूप करना पड़ता है और पाठ की तुलना करना पड़ता है, शायद मुंगिंग के साथ, और यह बहुत धीमी है।

पोस्ट स्थिति के नाम बदल सकते हैं, पोस्ट की स्थिति के बारे में अधिक जानकारी तालिका में जा सकती है, सब कुछ बस काम करता है यदि आप सामान्य करते हैं ।

उदाहरण के लिए, आप अतिरिक्त जानकारी के रूप में स्थिति स्तर जोड़ सकते हैं, जो तुलना बारूद के उल्लेख के लिए अनुमति देगा। लेकिन वे स्थिति के लिए कुंजी पर निर्भर नहीं करते हैं, DB अखंडता को नुकसान पहुँचाए बिना स्थिति स्तर के पुन: व्यवस्थित करने की अनुमति देते हैं। आप अतिरिक्त स्तर भी सम्मिलित कर सकते हैं, जो कि काफी चाल है यदि आपके पास ऑटोइन्क्रिमेंटिंग कुंजी से जुड़ा स्तर है।

Comments

आपके द्वारा यहां बताए गए कारण बिल्कुल वही कारण हैं जो मैंने अपने स्टॉस को स्टोर करने के लिए एक अन्य तालिका का उपयोग किया है। मुख्य कारण है कि मैंने यह सवाल पूछा है, यह देखने के लिए कि क्या कभी-कभी एक सरल पाठ क्षेत्र का उपयोग करना अच्छा है।

— शाकाहारी

@ लियम केवल अगर यह एक पाठ क्षेत्र के लिए सामान्य हो जाता है। यही है, यदि आपका पाठ क्षेत्र केवल प्राथमिक कुंजी पर निर्भर करता है, और आप प्राथमिक कुंजी के आधार पर चीजों को देख रहे हैं , तो पाठ क्षेत्र साथ आ रहा है। एक संबंधपरक DB संबंधों के बारे में है, आपके पास यहां एक है, इसलिए इसे परिभाषित करने की आवश्यकता है। कुछ अपवादों में से एक है यदि आप बाहर के स्रोत से गंदे डेटा को संभाल रहे हैं, और आपके पास इसे पूरी तरह से मॉडल करने का समय नहीं है। हो सके तो इससे बचें।

— स्पेंसर रथबुन

आँखों को छिपाता है, उन GUIDs का शोक

— मनाता है

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

— सनकैट २२

स्तंभ प्रकार बनाम पूर्ण तालिका स्कैन के बारे में गलत जानकारी के कारण अस्वीकृत।

— 4

Answer 4

हां, आपको विकल्प 2 के साथ जाना चाहिए, जिसमें पोस्टस्टैटस टेबल है।

अन्य उत्तरों में उल्लिखित सभी फायदों के अलावा।

यह ध्यान में रखते हुए कि स्थितियों को जोड़ने या निकालने की आवश्यकता है, आपके पास पोस्टस्टैटस तालिका में "सक्षम" कॉलम हो सकता है, इसलिए यदि स्थिति को हटा दिया जाता है तो "एन" के रूप में "सक्षम" कॉलम को चिह्नित करें, इस तरह आप सक्षम हो जाएंगे। जोड़ने और हटाने की स्थिति और भी मौजूदा रिकॉर्ड मुद्दों के बिना रहेंगे।

Answer 5

मैं अन्यथा व्यावहारिक जवाब देने के लिए जोड़ना चाहूंगा कि पूर्ण सामान्यीकरण के लिए, एक इकाई की स्थिति में बदलाव वास्तव में एक अलग इकाई में तैयार किया जाता है, जैसे 'स्टेटसचेंज'।

आपको स्टेटसचेंज इकाई के साथ एक अतिरिक्त जुड़ने की आवश्यकता होगी, लेकिन आप अतिरिक्त जानकारी जोड़ने की संभावना को जीतते हैं, जैसे कि अभिनेता परिवर्तन का प्रदर्शन कर रहा है, संभावित टिप्पणी क्यों परिवर्तन हुआ और एक तिथि जिस पर स्थिति परिवर्तन किया जाता है और संभवत: तब भी यह प्रभावी हो जाता है।

Answer 6

रिकॉर्ड तालिका में स्थिति के लिए पाठ का उपयोग करना शायद एक अच्छा विचार नहीं होगा क्योंकि यह बदल सकता है और सम्मिलित / अद्यतन पर किसी भी डेटा अखंडता की जांच करना मुश्किल होगा। यदि आप एक enum डेटाटाइप के साथ DBMS का उपयोग कर रहे हैं, तो आप इसके बजाय इसका उपयोग कर सकते हैं (प्रदर्शन संभवतः समझौता नहीं किया जाएगा ... निर्भर करता है)।

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

आप जो भी करते हैं, सुनिश्चित करें कि आप जादू की स्थिति से बचें (1 सक्रिय के लिए, 2 हटाए गए के लिए, ...)। यह प्रलेखन और परंपरा पर निर्भर करता है जो हमेशा एक बड़ी पर्याप्त समय पर खो जाने की प्रवृत्ति होती है। यदि आप सभी पर संख्यात्मक आईडी का उपयोग कर रहे हैं, तो सुनिश्चित करें कि आपके db में कहीं न कहीं एक टेक्स्ट एसोसिएशन है।

Comments

यदि आपको प्रदर्शन की चिंता नहीं है, तो आप स्केलेबिलिटी का त्याग कर रहे हैं। जादुई स्थिति से बचने के लिए कंप्यूटर के लिए असंभव है: 0 और 1 आंतरिक रूप से जादुई हैं।

— सनकैट २२

Answer 7

डेटाबेस डिजाइन के उद्देश्य पर निर्भर करता है।

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

Answer 8

स्टेटस बहुत महत्वपूर्ण है, किसी भी समय आपको पोस्ट की जानकारी मिलती है आपको इसकी स्थिति प्राप्त करने की आवश्यकता होगी, या आप पोस्ट को स्टेटस से फ़िल्टर करना चाहेंगे। यदि आपके पास किसी अन्य तालिका में स्थिति है, तो आपको यह जानकारी प्राप्त करने के लिए जॉइन करना होगा और इसलिए प्रदर्शन से समझौता किया जाएगा। निश्चित रूप से आपके पास एक ही तालिका में स्थिति होनी चाहिए। और उस पर एक सूचकांक रखो! आप अभी भी पूर्णांकों को स्टेटस या शायद एनम फील्ड के रूप में उपयोग कर सकते हैं।

Answer 9

सही समाधान CQRS या एक ब्लॉकचैन के साथ एक इवेंट स्टोर / स्रोत का उपयोग करना है। RDB में घटनाओं को कैप्चर करने में समस्या यह है कि RDB समय में किसी एकल घटना का स्नैपशॉट संग्रहीत करता है, और "स्टेटस / स्टेट्स" जैसी चीजें समय के साथ विकसित होने वाले उत्परिवर्तन का अनुक्रम होती हैं

Comments

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

— LastTribunal