एसक्यूएल: एक ईएनएन बनाम एक से अधिक रिश्ते बनाम लाभ?

Question

मैं शायद ही कभी जंगली में उपयोग की जाने वाली ईएनएम डेटाटाइप देखता हूं; एक डेवलपर लगभग हमेशा सिर्फ एक माध्यमिक तालिका कि इस तरह दिखता है का उपयोग करता है:

CREATE TABLE officer_ranks (
id int PRIMARY KEY 
,title varchar NOT NULL UNIQUE); 
INSERT INTO ranks VALUES (1,'2LT'),(2,'1LT'),(3,'CPT'),(4,'MAJ'),(5,'LTC'),(6,'COL'),(7,'BG'),(8,'MG'),(9,'LTG'),(10,'GEN'); 

CREATE TABLE officers (
solider_name varchar NOT NULL 
,rank int NOT NULL REFERENCES officer_ranks(id) ON DELETE RESTRICT 
,serial_num varchar PRIMARY KEY); 

लेकिन एक ही बात यह भी एक उपयोगकर्ता-निर्धारित प्रकार/enum का उपयोग कर दिखाया जा सकता है:

CREATE TYPE officer_rank AS ENUM ('2LT', '1LT','CPT','MAJ','LTC','COL','BG','MG','LTG','GEN'); 

CREATE TABLE officers (
solider_name varchar NOT NULL 
,rank officer_rank NOT NULL 
,serial_num varchar PRIMARY KEY); 

(PostgreSQL का उपयोग कर उदाहरण से पता चला , लेकिन अन्य आरडीबीएमएस के समान वाक्यविन्यास हैं)

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

मान लीजिए कि जानकारी अधिक स्थिर है (सप्ताह के नाम, महीने के नाम, अमेरिकी सेना रैंक इत्यादि) क्या ईएनएन का उपयोग करने का कोई फायदा है?

Answer 1

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

सरल प्रकारों के लिए जो नहीं बदलेगा मैंने डोमेन का सफलतापूर्वक उपयोग किया है। उदाहरण के लिए, मेरे डेटाबेस में से एक में मुझे एक yes_no_domain निम्नानुसार परिभाषित किया गया है:

CREATE DOMAIN yes_no_dom 
    AS character(1) 
    DEFAULT 'N'::bpchar 
    NOT NULL 
    CONSTRAINT yes_no_dom_check 
    CHECK ((VALUE = ANY (ARRAY['Y'::bpchar, 'N'::bpchar]))); 

साझा करें और आनंद लें।

Answer 2

मुझे ENUMS का उपयोग करने में कोई फायदा नहीं दिख रहा है।

वे बनाए रखने के लिए कठिन हैं और उचित विदेशी कुंजी के साथ एक नियमित लुकअप टेबल आपको कुछ भी करने की अनुमति नहीं देते हैं।

Answer 3

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

एक और लाभ किसी क्षेत्र के अनुमत मूल्यों के दस्तावेज़ीकरण के लिए है। उदाहरण:

• एक हाँ/नहीं क्षेत्र
• एक पुरुष/महिला क्षेत्र
• एक श्री/श्रीमती/एमएस/डॉ क्षेत्र

स्वाद का शायद एक मामले। मैं इस तरह के सरल अवधारणाओं के लिए टेबल देखने के लिए विदेशी कुंजी की बजाय, इन प्रकार के क्षेत्रों के लिए ईएनएन पसंद करता हूं।

फिर भी एक और फायदा यह हो सकता है कि जब आप जावा में jOOQ जैसे कोड पीढ़ी या ओआरएम का उपयोग करते हैं, तो आप उस ईएनएम का उपयोग जावा एनम क्लास उत्पन्न करने के लिए कर सकते हैं, लुकअप टेबल में शामिल होने के बजाय, या ईएनएम शाब्दिक आईडी के साथ काम कर सकते हैं

हालांकि, यह तथ्य है कि केवल कुछ आरडीबीएमएस औपचारिक ईएनएम प्रकार का समर्थन करते हैं। मुझे केवल पोस्टग्रेस और MySQL के बारे में पता है। ओरेकल या डीबी 2 में यह नहीं है।

Answer 4

सामान्य शब्दों में, enum चीजें हैं जो अधिक परिवर्तन नहीं के लिए बेहतर है, और यह थोड़ा कम संसाधनों का उपयोग करता है, वहाँ के बाद से कोई FK चेक या कुछ भी डालने आदि

पर अमल करने के लिए उपयोग करना एक लुकअप तालिका अधिक है पसंद सुरुचिपूर्ण और पारंपरिक और enum की तुलना में विकल्पों को जोड़ने और निकालना बहुत आसान है। एक enum की तुलना में मूल्यों को बड़े पैमाने पर बदलना भी आसान है।

Answer 5

उदाहरण PostgreSQL का उपयोग कर दिखाया गया है, लेकिन अन्य RDBMS के समान वाक्यविन्यास

यह गलत है की है। यह एक आईएसओ/आईईसी/एएनएसआई एसक्यूएल आवश्यकता नहीं है, इसलिए वाणिज्यिक डेटाबेस इसे प्रदान नहीं करते हैं (आपको लुकअप टेबल प्रदान करना होगा)। शहर के छोटे छोर विभिन्न "अतिरिक्त" लागू करते हैं, लेकिन शहर के बड़े छोर की कठोर आवश्यकताओं या गड़बड़ी को लागू नहीं करते हैं।

हमारे पास डेटाटाइप के हिस्से के रूप में ईएनएन नहीं है, यह बेतुका है।

ईएनएन का पहला नुकसान यह है कि यह गैर-मानक है और इसलिए पोर्टेबल नहीं है।

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

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

अंतिम, आप आसानी से ENUM की सामग्री की सूची नहीं प्राप्त कर सकते हैं; आप लुकअप टेबल के साथ कर सकते हैं। अधिक महत्वपूर्ण बात यह है कि आपके पास बड़ी फैक्ट टेबल और ग्रुप बाय से चयन करने की आवश्यकता को समाप्त करने के साथ किसी भी आयाम-तथ्य क्वेरी करने के लिए एक वेक्टर है।

Answer 6

लाभ: संग्रहित प्रक्रियाओं के लिए

• प्रकार की सुरक्षा: एक प्रकार की त्रुटि को बढ़ाने अगर तर्क प्रकार मजबूर नहीं किया जा सकता होगा। पसंद: select court_martial('3LT') स्वचालित रूप से एक प्रकार की त्रुटि उठाएगा।

• कस्टम गठबंधन आदेश: आपके उदाहरण में, अधिकारियों को रैंकिंग आईडी के बिना क्रमबद्ध किया जा सकता है।

Answer 7

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

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

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