2012-01-09 14 views
14

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

+1

"सभी गणनाओं के लिए एक लुकअप टेबल", उर्फ ​​"एक ट्रू लुकअप टेबल", उर्फ ​​"ओटीएलटी", एक प्रसिद्ध एसक्यूएल विरोधी पैटर्न है। आप Google कर सकते हैं। मैं तर्क दूंगा कि गणना स्वयं डेटाबेस विरोधी पैटर्न हैं, क्योंकि वे विस्तार (अतिरिक्त विशेषताओं) को आसानी से समायोजित नहीं करते हैं। –

उत्तर

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

  2. बाधा की तुलना में तालिका में नए मान जोड़ने के लिए भी बहुत आसान है।

  3. यदि आप डेटाबेस आरेख बनाते हैं, तो व्यक्तिगत लुकअप टेबल अधिक तार्किक दिखाई देते हैं।

  4. यदि आवश्यक हो तो आप व्यक्तिगत लुकअप टेबल पर अतिरिक्त जानकारी जोड़ सकते हैं (जैसे टिप्पणी, एक प्रकार का कॉलम, कुछ प्रकार का ध्वज इत्यादि)।

  5. और जैसा कि आप ने कहा है, यह रेफेरेंन्शिअल सत्यनिष्ठा

हालांकि के लिए बेहतर है; यदि आप कोड-प्रथम दृष्टिकोण के साथ ओ/आर-मैपर का उपयोग कर रहे हैं, प्रोग्रामिंग भाषा द्वारा प्रदान किए गए एनम का उपयोग करके काफी प्राकृतिक लगता है। ऐसा इसलिए है क्योंकि आप डेटाबेस को डिज़ाइन नहीं कर रहे हैं लेकिन ऑब्जेक्ट मॉडल हैं। ओ/आर-मैपर स्वचालित रूप से आपके लिए डेटाबेस बनाता है।

0

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

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

"एक सच्ची लुकअप टेबल" आपको कोई लाभ नहीं दे रहा है।

संपादित करें: यदि आपको गतिशील रूप से enum मानों को पुनर्प्राप्त करने की आवश्यकता है (उदा। ड्रॉपडाउन के लिए) या यह जानने की आवश्यकता है कि कौन से मानों की अनुमति है, तो लुकअप टेबल का उपयोग करना शायद आपके लिए बेहतर है।

+0

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

+0

यदि आपको 'SELECT' कथन का उपयोग करके अनुमत मानों को देखने की आवश्यकता है, तो आपके लिए एक लुकअप तालिका शायद बेहतर है। "केवल एक तालिका में उपयोग किया जा सकता है" के बारे में: यह कुछ समय हो गया है क्योंकि मैंने SQL सर्वर का उपयोग किया था। PostgreSQL में मैं एक नया 'डोमेन' परिभाषित करता हूं जो चेक बाधा को समाहित करता है और इसे पुनः उपयोग करने योग्य बनाता है। हो सकता है कि SQL सर्वर में कुछ भी समान हो। –

+0

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

0

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

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

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