व्यावसायिक तर्क में डेटाबेस मानों को संदर्भित करना

43

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

1 Apple 
2 Banana 
3 Grapes

मैं उन्हें उपयोगकर्ता के लिए प्रस्तुत कर सकता हूं, वह एक का चयन करता है, यह उसके प्रोफाइल में FavouriteFruit और डेटाबेस में अपने रिकॉर्ड में संग्रहीत आईडी के रूप में संग्रहीत हो जाता है।

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

// Hard coded name
if (user.FavouriteFruit.Name == "Grapes")

// Hard coded ID
if (user.FavoriteFruit.ID == 3) // Grapes

// Duplicate the list of fruits in an enum
if (user.FavouriteFruit.ID == (int)Fruits.Grapes)

या कुछ और?

बेशक FavouriteFruit आवेदन भर में इस्तेमाल किया जाएगा, सूची में जोड़ा या संपादित किया जा सकता है।

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

हार्डकोड आईडी पूरी तरह से स्पष्ट नहीं है, हालांकि, जैसा कि दिखाया गया है कि आप जल्दी से यह पता लगाने के लिए एक टिप्पणी जोड़ सकते हैं कि यह किस मद में है।

एनुम विकल्प में डेटाबेस से डेटा को डुप्लिकेट करना शामिल है जो गलत लगता है क्योंकि यह सिंक से बाहर निकल सकता है।

वैसे भी, किसी भी टिप्पणी या सुझाव के लिए अग्रिम धन्यवाद।

design

— केट
स्रोत

1

सभी का धन्यवाद: सुझाव और सामान्य सलाह वास्तव में मददगार है। @RemcoGerlich प्रदर्शन उद्देश्यों के लिए उपयोग की जाने वाली स्ट्रिंग की चिंताओं को अलग करने के लिए अपने विचार और अधिक पठनीय कोड के लिए एक लुकअप कोड के रूप में एक बहुत अच्छा है।

— केट

1

मैं देने जा रहा हूँ @ माइक नकीस आपके प्रीलोडेड ऑब्जेक्ट्स को एक विचार लगता है, हालांकि यह दोनों दुनिया के सर्वश्रेष्ठ की तरह लगता है।

— केट

1

मैं आपके पहले समाधान पर एक बदलाव का सुझाव दूंगा। क्या आपकी तालिका में एक 3 कॉलम है, इसे कैसे संसाधित किया जाएगा, और आप उस फ़ील्ड का उपयोग यह निर्धारित करने के लिए करते हैं कि किस कोड को निष्पादित करना है। प्रदर्शन क्षेत्र नहीं, और कई फलों के बीच साझा किया जा सकता है।

— किकस्टार्ट

1

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

— राडारबोब

1

हम्म् ... अगर एक स्ट्रिंग के लिए ID का 1: 1 संबंध है तो यह बेमानी है और दोनों का होना व्यर्थ है। स्ट्रिंग केवल DB कुंजी के साथ-साथ पूर्णांक के रूप में भी काम कर सकता है। MyApplication.Grape.IDहकलाना है, इसलिए बोलना है। एक "Apple" एक "Red_Apple" नहीं है, 3 की ID से भी अधिक 4 भी है। इसलिए "Apple" को "Red_Apple" में बदलने की क्षमता से कोई मतलब नहीं है कि 3 घोषित करने की तुलना में 4 है (और शायद 3 भी)। एक एनुम का बिंदु अपने संख्यात्मक डीएनए को दूर करना है। तो शायद यह वास्तव में मनमाने ढंग से संबंधपरक डीबी कुंजियों को अपघटित करने का समय है जिनका शाब्दिक अर्थ किसी के व्यवसाय मॉडल में नहीं है।

— राडारबॉब

31

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

if( user.FavouriteFruit.ID == MyApplication.Grape.ID )

अभी यहाँ क्या हुआ है, मैंने स्पष्ट रूप से पूरी पंक्ति Grapeको मेमोरी में लोड किया है, इसलिए मेरे पास इसकी आईडी तुलना में उपयोग करने के लिए तैयार है। यदि आप ऑब्जेक्ट-रिलेशनल मैपिंग (ORM) का उपयोग कर रहे हैं, तो यह और भी अच्छा लगता है:

if( user.FavouriteFruit == MyApplication.Grape )

(इसलिए मैं इसे "प्रीलोडेड ऑब्जेक्ट्स" कहता हूं।)

तो, मैं क्या करता हूं कि स्टार्टअप के दौरान मैं अपने सभी "एन्यूमरेशन" टेबल (सप्ताह के दिनों की तरह छोटी टेबल, साल के महीने, जेंडर आदि) को मुख्य एप्लिकेशन डोमेन वर्ग में लोड करता हूं। मैं उन्हें नाम से लोड करता हूं, क्योंकि जाहिर है, MyApplication.Grape"ग्रेप" नामक पंक्ति को प्राप्त करना होगा, और मैं दावा करता हूं कि उनमें से प्रत्येक को मिला है। यदि नहीं, तो स्टार्टअप के दौरान हमारे पास गारंटीकृत रन-टाइम त्रुटि है, जो सभी रन-टाइम त्रुटियों के लिए सबसे कम घातक है।

— माइक नाकिस
स्रोत

17

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

— कॉन्स्टेंट

2

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

— माइक नाकिस

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

— svidgen

1

@ user469104 अंतर यह है कि आईडी बदल सकते हैं, और आवेदन अभी भी सभी पंक्तियों को सही ढंग से लोड करेगा और सभी तुलनाओं को सही ढंग से करेगा। इसके अलावा, आप कोड को रीफ़्रैक्टर करने के लिए स्वतंत्र हैं और आप जो भी चाहते हैं, उसमें पंक्तियों का नाम बदल सकते हैं, और एकमात्र स्थान जहां आपको ठीक करने के लिए सामान की तलाश में जाना है, आवेदन के स्टार्टअप में है, और यह बहुत स्पष्ट हो जाता है: Grape = fetchRow( Fruit.class, NameColumn, "Grape" ); और यदि आप गलत तरीके से कुछ करना, AssertionErrorआपको पता चल जाएगा।

— माइक नाकिस

1

@grahamparks से अधिक enumकोई जादू स्ट्रिंग नहीं होता। बिंदु केवल एक ही स्थान पर सभी बाइंडिंग-नेम की सांद्रता है , स्टार्टअप के दौरान यह सभी का सत्यापन , और प्रकार की सुरक्षा ।

— माइक नाकिस

7

स्ट्रिंग के खिलाफ जांच करना सबसे अधिक पठनीय है, लेकिन यह दोहरा कर्तव्य करता है: इसका उपयोग पहचानकर्ता और विवरण (दोनों असंबंधित कारणों से बदल सकता है) के रूप में किया जाता है।

मैं आमतौर पर दोनों कर्तव्यों को अलग-अलग क्षेत्रों में विभाजित करता हूं:

id  code    description
 1  grape   Grapes
 2  apple   Apple

जहां वर्णन बदल सकता है (लेकिन "अंगूर" से "केला" नहीं), लेकिन कोड को बदलने की अनुमति नहीं है, कभी भी।

हालांकि यह ज्यादातर इसलिए है क्योंकि हमारी आईडी लगभग हमेशा ऑटो-जेनरेट की जाती है, और इस तरह यह एक अच्छा फिट नहीं है। यदि आप स्वतंत्र रूप से आईडी चुन सकते हैं, तो शायद आप गारंटी दे सकते हैं कि वे हमेशा सही हैं और उन का उपयोग करें।

इसके अलावा, कितनी बार कोई व्यक्ति "अंगूर" को "अंगूर" में वास्तव में संपादित करता है ? शायद इसमें से कुछ भी आवश्यक नहीं है।

— RemcoGerlich
स्रोत

8

मुझे नहीं लगता कि अभी और अतिरेक का जवाब है ...

— Robbie Dee

4

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

— माइक नाकिस

1

मुझे आपकी प्रीलोडेड वस्तुएं ज़रूर पसंद हैं, लेकिन अगर आपका "सेब" विभेदित है, तो क्या आपको वैसे भी सब कुछ खत्म करने की ज़रूरत नहीं है, जो भी विधि आपको चुनना है?

— रेमकोगर्लिच

अंतर्राष्ट्रीयकरण के समर्थन में आपके पास विवरण नाम के लिए एक अलग तालिका भी हो सकती है।

— एरिक Eidt

1

@MikeNakis और Refactoring अनिवार्य रूप से Fruit.Apple के साथ Fruit.Apple की जगह आपके पूरे कोडबेस की खोज और प्रतिस्थापन है। अगर मैं हार्डकोडिंग स्ट्रिंग वैल्यू का उपयोग करता हूं तो मैं "सेब" को "ग्रीन_एप्पल" से बदलने के लिए पूरे कोडबेस पर एक खोज और प्रतिस्थापन करूंगा जो कि उसी चीज के बारे में है। - Refactoring सिर्फ बेहतर महसूस करती है, क्योंकि IDE रिप्लेसमेंट कर रही है।

— फाल्को

4

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

कुछ पैटर्न जो मैंने देखे हैं:

आपके प्रोग्राम के दिन को बर्बाद करने वाले एक नए डेटाबेस प्रविष्टि से सुरक्षा के लिए Enums + डिफ़ॉल्ट।
डेटाबेस में ही किए जाने वाले कार्यों (बिज़ लॉजिक) का एनकोडिंग। कई मामलों में यह बहुत संभव है क्योंकि कई लॉजिक्स का पुन: उपयोग किया जाता है। तर्क का क्रियान्वयन कार्यक्रम में होना चाहिए।
कार्यक्रम में 'सही-नज़रअंदाज़' के रूप में ब्रांड के नए मूल्य को चिह्नित करने के लिए डेटाबेस में अतिरिक्त विशेषताएँ / कॉलम प्रोग्राम को सही तैनात किए जाने तक।
कोड पथ के चारों ओर तेजी से तंत्र को विफल करता है जो डेटाबेस से मानों को लोड / पुनः लोड करता है। (यदि संबंधित कार्रवाई कार्यक्रम में नहीं है और इसे नजरअंदाज करने के लिए चिह्नित नहीं किया गया है, तो ताज़ा न करें)।

सामान्य तौर पर मुझे यह पसंद है कि डेटा उन कार्यों के संदर्भ में पूरा हो जाता है, जो इसका तात्पर्य है - भले ही क्रियाएं स्वयं कहीं और कार्यान्वित की जा सकती हैं। डेटा से स्वतंत्र होने वाली क्रियाओं का निर्धारण करने वाले किसी भी कोड ने आपके डेटा प्रतिनिधित्व को तेज कर दिया है, जो संभवतः सबसे अधिक परिवर्तन करेगा और बग को जन्म देगा।

— सुबु शंकर सुब्रमण्यन
स्रोत

4

उन्हें दोनों स्थानों पर (एक तालिका में और एक ENUM में) संग्रहीत करना उतना बुरा नहीं है। तर्क निम्न है:

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

एक ENUM के रूप में उन्हें संग्रहीत करना भी समझ में आता है क्योंकि हम जादू के तार के बिना कोड लिख सकते हैं और यह कोड को अधिक पठनीय बनाता है। हां, उन्हें सिंक में रखना होगा, लेकिन वास्तव में ENUM के लिए एक लाइन और डेटाबेस में एक नया इंसर्ट स्टेटमेंट जोड़ना कितना कठिन होगा।

एक बात, एक बार ENUM परिभाषित हो जाने के बाद, इसका मूल्य नहीं बदलें। उदाहरण के लिए, यदि आपके पास:

सेब
अंगूर

अंगूर को अंगूर का नाम नहीं दें। बस एक नया ENUM जोड़ें।

सेब
अंगूर
अंगूर

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

— जॉन रेन्नोर
स्रोत

एक और कदम के रूप में मैंने उन दुकानों में काम किया है जहाँ मेटाडेटा मानों को तालिका में हटाए जाने वाले झंडे में संकेत मिलता है कि उनका उपयोग नहीं किया जाना चाहिए (वे या तो हटा दिए गए हैं या एक नया संस्करण मौजूद है)।

— रॉबी डी डे

1

आप इस सवाल को पूछना सही है, यह एक अच्छा सवाल है क्योंकि आप गलत परिस्थितियों के मूल्यांकन से बचाव का प्रयास कर रहे हैं।

यह कहा, मूल्यांकन (आपकी ifशर्तों) जरूरी नहीं कि आप इसके चारों ओर कैसे हो ध्यान केंद्रित करने की जरूरत है। इसके बजाय, उन तरीकों पर ध्यान दें, जिनसे आप उन परिवर्तनों का प्रचार करते हैं, जो 'सिंक से बाहर' समस्या का कारण बनते हैं।

स्ट्रिंग दृष्टिकोण

यदि आपको स्ट्रिंग्स का उपयोग करना चाहिए, तो यूआई के माध्यम से सूची को बदलने की कार्यक्षमता को उजागर क्यों नहीं करना चाहिए? सिस्टम को डिज़ाइन करें ताकि बदलने Grapeपर Grapes, उदाहरण के लिए, आप वर्तमान में संदर्भित सभी रिकॉर्डों को अपडेट कर दें Grape।

आईडी दृष्टिकोण

कुछ पठनीयता के समझौता के बावजूद, मैं हमेशा एक आईडी का संदर्भ लेना चाहूंगा। The list may be added toयदि आप ऐसी UI सुविधा को उजागर करते हैं, तो आपको फिर से सूचित किया जा सकता है। यदि आप आईडी बदलने वाली वस्तुओं के पुन: निर्धारण से चिंतित हैं, तो इस तरह के परिवर्तन को फिर से सभी आश्रित रिकॉर्ड में बदल दें। इसी तरह ऊपर। एक अन्य विकल्प (उचित सामान्यीकरण सम्मेलन के बाद, आपका एनम / आईडी कॉलम होगा - और एक अधिक विस्तृत FruitDetailतालिका का संदर्भ दें , जिसमें एक 'ऑर्डर' कॉलम है जिसे आप देख सकते हैं)।

किसी भी तरह से, आप देख सकते हैं कि मैं आपकी सूची के संशोधन या अद्यतन को नियंत्रित करने का सुझाव दे रहा हूं। चाहे आप एक ORM के उपयोग के माध्यम से करते हैं या कुछ अन्य डेटा एक्सेस आपकी तकनीक की बारीकियों द्वारा निर्धारित किया जाता है। आप जो कर रहे हैं, अनिवार्य रूप से, करने के लिए आवश्यक है कि लोग ऐसे परिवर्तनों के लिए DB से दूर रहें - जो मुझे लगता है कि ठीक है। अधिकांश मुख्य CRM समान आवश्यकता बनाएंगे।

— JᴀʏMᴇᴇ
स्रोत

1

डेटाबेस में , विशेष रूप से उस समस्या से बचने के लिए, बाल रिकॉर्ड के लिए संख्यात्मक आईडी संग्रहीत की जा रही है। यह सवाल एक प्रोग्रामिंग भाषा में इंटरफ़ेस करने के तरीके के बारे में है।

— क्लॉकवर्क-

1

@ क्लॉकवर्क-म्यूजियम - किस समस्या से बचने के लिए? इसका कोई मतलब नहीं है।

— J --Mᴇᴇ 15

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

— ब्रायन नॉबलुच

यदि आप आईडी दृष्टिकोण के साथ जाते हैं, तो आप विकास बनाम उत्पादन डेटाबेस से कैसे निपटते हैं? ऑटो-इंक्रीमेंट आईडी के साथ, अलग-अलग क्रम में दोनों डीबी में आइटम जोड़ने से अलग-अलग आईडी का परिणाम होगा।

— रक्षक

हालांकि ऑटो वेतन वृद्धि नहीं है? यह इस मामले में नहीं होना चाहिए, खासकर अगर यह अंतर्निहित एनम के पूर्णांक मूल्य का उपयोग कर रहा है।

— J --Mᴀʏ

0

एक बहुत ही आम समस्या। डेटा क्लाइंट साइड को डुप्लिकेट करते समय DRY सिद्धांतों का उल्लंघन हो सकता है , यह वास्तव में परतों के बीच प्रतिमान के अंतर के कारण है।

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

यह कभी-कभी दूसरे तरीके से भी होता है। एक नया एनम वैल्यू क्लाइंट साइड में जोड़ा जाता है लेकिन डीबी अपडेट तब तक नहीं हो सकता जब तक कि डीबीए परिवर्तन लागू नहीं कर सकता।

— रोबी डी
स्रोत

हां, आपने समस्या का वर्णन किया है। आपका समाधान क्या है?

— रक्षक एक

1

@Protectorone आप मानते हैं कि एक चांदी की गोली समाधान है जो मेरे अनुभव में एक गलत धारणा है। आपके लिए सबसे अच्छी उम्मीद यह हो सकती है कि कुछ व्यावसायिक संस्था समस्या डोमेन का मालिक है, इसलिए कम से कम आप देख सकते हैं कि कौन सा पक्ष पिछड़ रहा है - ग्राहक पक्ष या डेटाबेस पक्ष। बैंकिंग और वित्त आम तौर पर इस संबंध में बहुत कुशल हैं कि खुदरा क्षेत्र काफ़ी कम है इसलिए ...

— रॉबी डी

0

यह मानते हुए कि हम इस बारे में बात कर रहे हैं कि मूल रूप से एक स्थिर लुकअप है तो तीसरा विकल्प - एनम - मूल रूप से एकमात्र विकल्प है। अगर डेटाबेस शामिल नहीं था तो इसका आप क्या करेंगे तो यह समझ में आता है।

तब सवाल यह हो जाता है कि डेटाबेस में एनम और स्टेटिक / लुकअप टेबल्स को कैसे सिंक में रखा जाए और दुर्भाग्य से यह एक समस्या नहीं है जिसका मेरे पास अभी तक पूरा जवाब नहीं है।

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

— Murph
स्रोत

1

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

— रॉबी डी डे

ठीक है, मुझे एक बेहतर पद की आवश्यकता है "स्टेटिक लुकअप के लिए" आपके द्वारा वर्णित प्रसंग का यही मतलब है कि :) कुंजी "स्टैटिक" है - ये ऐसे मान हैं जो समस्या को बदलते नहीं हैं नए मान जोड़ रहे हैं और "लेबल" को बदल रहे हैं ( मौजूदा मूल्यों के लिए लेकिन इरादे नहीं)।

— मर्फ़