मेरे लिए यह एप्लिकेशन कोड में निरंतर चर के बजाय हार्डकोडेड मानों का उपयोग करना है। लेकिन वहाँ अलग राय हैं। तो मैं वास्तव में निश्चित रूप से तय नहीं कर सकता।mysql ENUM का उपयोग एक खराब वास्तुकला समाधान का उपयोग कर रहा है?
पीएस इस सवाल के दायरे के लिए हम मान लें कि प्रदर्शन कोई मुद्दा नहीं है।
यह वास्तव में प्राप्त करने की कोशिश कर रहे हैं, इस पर निर्भर करता है। यदि प्रदर्शन, जैसा कि आप कहते हैं, कोई मुद्दा नहीं है, तो यह आपके दर्शन के लिए काफी हद तक नीचे है, और डेटा की अंतर्निहित परिवर्तनशीलता है। यदि आप सप्ताह के दिनों के लिए मूल्यों को स्टोर करने के लिए ईएनएन का उपयोग कर रहे हैं, मानव पठनीयता और डेटा की 'पूछताछ' की सहायता के लिए, तो यह एक पूरी तरह से वैध उपयोग है (और कुछ मामलों में, संख्याओं का उपयोग करने के लिए, या अन्य अभ्यावेदन)। यदि, हालांकि, आप इसे उस श्रेणी की श्रेणी जैसे सामानों को स्टोर करने के लिए उपयोग कर रहे हैं (जिसके लिए उपलब्ध श्रेणियों का सेट आसानी से बदल सकता है), तो यह एक बहुत ही खराब समाधान है।
यह वास्तविक स्थिति पर बहुत निर्भर करता है, लेकिन पहली जगह कॉलम प्रकारों का बिंदु यह निर्धारित करना है कि कौन से मूल्यों की अनुमति है और कौन नहीं हैं। यदि, आपकी समस्या डोमेन में, विशेषता जिसे आप ENUM मान के रूप में स्टोर करने पर विचार कर रहे हैं, निश्चित है, इस अर्थ में कि यह अन्य मानों को संभव नहीं हो सकता है, तो ENUM एक बेहतरीन विकल्प है। इसका एक उदाहरण लिंग होगा: ENUM('male', 'female') बहुत अच्छा है, क्योंकि तीसरे लिंग को जोड़ने का मौका वास्तव में बहुत कम होगा।
यदि आप उन मूल्यों को संग्रहीत कर रहे हैं जो बदलने की अधिक संभावना रखते हैं, तो आप इसके बजाय अपने डेटा मॉडल को एक-से-एक रिश्ते को सामान्यीकृत करने पर विचार कर सकते हैं।
मान लीजिए कि आपको इसे किसी अन्य भाषा में अनुवाद करना है, या मान लीजिए कि व्यवसाय निर्देश देता है कि आप इसके बजाय 'एम' और 'एफ' स्वीकार करते हैं। – MattK
@MattK वे एप्लिकेशन/इंटरफ़ेस चिंताओं हैं, डेटा चिंता नहीं। – molf
मैं देख रहा हूं कि आप क्या कह रहे हैं, लेकिन ईएनएम पहले से ही डेटा के साथ इंटरफेस मिश्रण कर रहा है। अगर हम यह शुद्ध डेटा चाहते थे, तो बस 0 और 1 का उपयोग करें। यदि आप चाहते हैं कि आपके डीबी के पास कुछ और पठनीय (जैसे कि 'पुरुष' और 'मादा') हो तो क्या होगा यदि डेटा को बदलने की भविष्य की आवश्यकता है (जैसे अंतर्राष्ट्रीयकरण)? – MattK
किसी भी तरह से नहीं! उनके पास संख्यात्मक क्षेत्र पर कई फायदे हैं:
वास्तव में, enums के बजाय संख्यात्मक मान का उपयोग कर स्रोत कोड में स्थिरांक डालने की तरह है।
ईएनएन डेटा के लिए बहुत अच्छा है जो आपको पता है कि एक स्थिर सेट में आ जाएगा।
यदि आप माइस्क्ल 5+ का उपयोग कर रहे हैं, तो स्टोरेज is almost always better एक स्थिर सेट में डेटा के लिए ENUM प्रकार के साथ, आधिकारिक MySQL संदर्भ दिखाता है। उल्लेख नहीं है कि डेटा पठनीय है, और आपके पास सत्यापन की एक अतिरिक्त परत है।
यदि आप जानना चाहते हैं कि ENUM का उपयोग करना एक अनुकूलन होगा, तो मैं PROCEDURE ANALYZE का उपयोग करने की सलाह देता हूं। यह आपके कॉलम के लिए उचित डेटा प्रकार की अनुशंसा करेगा।
व्यावहारिक दोष विस्तारशीलता है। आप पूरी तालिका को अपडेट किए बिना सूची में कोई मूल्य नहीं जोड़ सकते हैं। आप ऐतिहासिक होने के लिए मूल्यों को चिह्नित नहीं कर सकते हैं। मूल्यों की सूची सीमित है। यद्यपि आप सूची सुविधा को अपने आवेदन के एमवीसी मॉडल में ले जाने के दौरान दोनों में सर्वश्रेष्ठ हो सकते हैं और कॉलम प्रकार को CHAR होने दें। जब तक प्रदर्शन और संग्रहण आपके आवेदन की कुंजी न हो, तब तक जब मैं केवल अनुप्रयोगों द्वारा डेटाबेस का उपयोग नहीं करता, तो मैं enums का उपयोग करने की अनुशंसा नहीं करता। – Code4R7