लुकअप टेबल्स: क्या वे डोमेन मॉडल में एक रिसाव है?

Question

आप एक ऐसी प्रणाली बना रहे हैं, जो कंपनियों पर नज़र रखती है। उन कंपनियों के संपर्क हैं। वे संपर्क अक्सर विशेषज्ञ होते हैं जो केवल कुछ प्रकार के प्रश्नों का उत्तर देते हैं, जैसे बिलिंग / भुगतान, बिक्री, ऑर्डरिंग और ग्राहक सहायता।

डोमेन संचालित डिज़ाइन और एक प्याज वास्तुकला का उपयोग करते हुए, मैंने इसे निम्न प्रकारों से तैयार किया है:

• कंपनी
  • संपर्क है
• संपर्क करें
  • संपर्क प्रकार हैं
• ContactType (एनम)
• CompanyRepository (इंटरफ़ेस)
• EFCompanyRepository (बाहरी विधानसभा में परिभाषित, EntityFramework, कार्यान्वयन CompanyRepository) का उपयोग करता है

हमारी टीम के पास इस एप्लिकेशन के लिए डेटाबेस को मॉडल करने के बारे में एक अलग राय है।

साइड ए: लीन डीडीर्स:

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

साइड बी: द ट्रेडिशनलिस्ट [कि शायद एक उचित नाम नहीं है। DBCentrists?]:

• डेटाबेस में डेटा रखना एक बुरा विचार है जो बिना कोड को पढ़े समझ में नहीं आता है। रिपोर्ट और अन्य उपभोक्ताओं को स्वयं मूल्यों की सूची दोहरानी होगी।
• यह मांग पर अपने डीबी टाइप शब्दकोशों को लोड करने के लिए इतना कोड नहीं है। इसके बारे में चिंता मत करो।
• यदि इसका स्रोत कोड है और डेटा नहीं है तो मुझे एक साधारण SQL स्क्रिप्ट के बजाय बिट्स को तैनात करना होगा जब यह बदलता है।

न तो पक्ष सही है या गलत है, लेकिन उनमें से एक संभवतः लंबे समय में अधिक कुशल है, प्रारंभिक विकास, कीड़े, आदि के लिए विकास के समय की गिनती कर रहा है कि यह कौन सा पक्ष है - या क्या एक बेहतर समझौता है? कोड की इस शैली को लिखने वाली अन्य टीमें क्या करती हैं?

Comments

मैं डेटाबेस में लुकअप टेबल रखना पसंद करता हूं और कोड (T4 टेम्प्लेट .NET में) है जो मेरे एप्लिकेशन कोड में लुकअप टेबलों के आधार पर मेरे लिए एनमोंस बनाता है।

— प्रोग्रामर

@JasonHolland क्या T4 टेम्पलेट वास्तव में एक क्वेरी करता है? अन्यथा मुझे यकीन नहीं है कि यह अपेक्षित नाम के साथ खाली एनम से अधिक कैसे उत्पन्न होता है।

— ड्रू

हाँ यह एक क्वेरी करता है। Developerhandbook.com/c-sharp/t4-templates-for-lookup-tables और iraticdev.blogspot.com/2011/01/…

— प्रोग्रामर

स्थिर मूल्यों वाली तालिका के लिए, आपको कितना CRUD कोड लिखना होगा? इसे स्क्रिप्ट करें और किया जाए।

— जेफ़ओ

'अच्छी तरह से, यह रिपोर्टिंग के लिए कोई मतलब नहीं होगा' के बारे में पारंपरिक CRUD-ist तर्क एक गैर स्टार्टर है। जैसे ही आप कुछ अन्य ज़िम्मेदारी का परिचय देते हैं, जो आपके पास है (सिस्टम को समझाना, रिपोर्ट करना), आपको एक व्यावसायिक आवश्यकता मिल गई है जिसे उचित रूप से नियंत्रित करने की आवश्यकता है। डेटाबेस अनुप्रयोगों को स्वयं, संरक्षित स्थिति को संग्रहीत और लोड करने के लिए है; इसे रिपोर्ट करने की अनुमति देना आपके आवेदन और रिपोर्ट की आवश्यकता वाले लोगों के बीच युग्मन बनाता है। यदि DDD इन संदर्भों को अलग करने के बारे में कुछ भी है।

— मैट

Answer 1

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

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

Answer 2

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

उस ने कहा, मुझे लगता है कि आपके DBCentrists नाव को याद कर रहे हैं। डोमेन मॉडलर्स कह रहे हैं कि उन्हें एक दृढ़ता स्टोर की आवश्यकता है। "रिपोर्ट और अन्य उपभोक्ताओं" को कुछ ऐसी चीज़ों की आवश्यकता होती है जो वे क्वेरी कर सकते हैं - कुछ सभ्य सूचकांक के साथ, जैसा कि टिप्पणियों में नोट किया गया है।

किसने अड़चन पेश की कि इन सभी विभिन्न चिंताओं को एक डेटाबेस द्वारा समर्थित करने की आवश्यकता है? यदि आप उस पर वापस धक्का देते हैं तो क्या होता है।

खोज कीवर्ड: CQRS।

Answer 3

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

स्पष्ट रूप से इसका नकारात्मक पक्ष यह है कि यह अधिक डिस्क स्थान का उपयोग करता है और सामान्यीकृत नहीं होता है।

प्लस पक्ष यह है कि फ़ील्ड db में इसका अर्थ बनाए रखता है, आप उदाहरण के लिए enum के इंटिम वैल्यू के लिए संक्षारक संख्या के साथ समाप्त नहीं होते हैं और जब Enum में परिवर्तन होता है, तो आपको लुकअप टेबल को संस्करणबद्ध करने की आवश्यकता नहीं होती है।

मुझे यकीन नहीं है कि मैं इसे डीडीडी बनाम पारंपरिक अंतर के रूप में दिखाऊंगा। इसका अधिक डेटाबेस-केंद्रवादी बनाम कोड मेरे विचार में सबसे अच्छा है

Comments

सोच रहा था कि क्या डेटाबेस में इन दिनों ऐसी कोई विशेषता है

— herzmeister

मुझे लगता है कि यह DB पर निर्भर करेगा, आप MSSQL के साथ सभी प्रकार के पागल सीएलआर सामान कर सकते हैं। लेकिन मैं दृढ़ता से 'डीबी खराब, कोड अच्छा' पक्ष के साथ हूं जब यह ऐसी चीजों की बात आती है

— इवान

@herzmeister <3 PostgreSQL postgresql.org/docs/9.4/static/datatype-enum.html , Ewan DB एक बार कोड होता है जब आप संग्रहीत प्रक्रियाओं को अपनाते हैं। (PLv8 अद्भुत है)।

— सिरियनियन

@ चीनी आप जानते हैं कि यह बात मिश्रण है? मेरा भी वही सवाल है। "क्या यह पैमाना है?"

— इवान

क्या आपका मतलब है कि एनम को एक स्ट्रिंग में बदलने के लिए यह एक क्रॉस उत्पाद करता है? शायद ऩही। मुझे यकीन नहीं है कि इसे कैसे लागू किया गया है, लेकिन यह एक अलग तालिका का उपयोग करने की तुलना में तेज़ है। यह तराजू है। यह भी मिला: stackoverflow.com/questions/2318123/… फिर भी 5 साल बाद एक वैध मूल्यांकन की तरह लगता है। (मैं PostgreSQL के लिए अत्यधिक युग्मित कार्यक्रमों को लिखने के लिए हूं, इसलिए मैं सभी सुविधाओं का उपयोग करता हूं, लेकिन हर कोई ऐसा नहीं कर सकता है)।

— सिरिसियन

Answer 4

• जब तक आप एक संबंधपरक डेटाबेस का उपयोग कर रहे हैं तब तक आपको तालिकाओं को एक उचित सीमा तक सामान्य रखना चाहिए। सामान्यीकरण सम्मिलित करने और विसंगतियों को अद्यतन करने से रोकने में मदद करता है।
• वन-ऐप <-> वन-डेटाबेस रिलेशनशिप अब सामान्य नहीं है, कई ऐप कई डेटाबेस का उपयोग कर सकते हैं और एक ही डेटाबेस का उपयोग कई ऐप द्वारा किया जा सकता है, इसलिए डेटाबेस में जितना संभव हो सके संदर्भात्मक अखंडता लागू होती है।
• RDBMS आपका मित्र है।
• आप इसके बजाय एक कुंजी-मूल्य संग्रहण के साथ जा सकते हैं और कोड में सब कुछ कर सकते हैं।