इसके लायक पूर्णांकों में कनवर्ट डेटाबेस स्ट्रिंग enums है? एक स्ट्रिंग के रूप में या एक पूर्णांक के रूप में:

Question

वहाँ डेटाबेस में enum प्रकार स्टोर करने के लिए दो तरीके हैं।

गणना को सहेजना (sex = {male,female}, account_type = {regular,pro,admin}, आदि) क्योंकि स्ट्रिंग चीजों को और अधिक पठनीय बनाती है लेकिन पूर्णांक की तुलना में अधिक जगह की आवश्यकता होती है।

दूसरी ओर, पूर्णांक को डेटाबेस में और बाहर enums मैपिंग की आवश्यकता होती है। लाभ के रूप में, डेटाबेस के बाहर पूर्णांक वाले केस-सेंसिटीविटी को संभाला जाता है।

मान लीजिए कि दोनों अनुक्रमित हैं, आम तौर पर इसके पूर्णांक रूपांतरण को कर रहे हैं? पूर्णांक के साथ लुकअप कितनी तेजी से है?

उदाहरण

शायद एक ठोस उदाहरण बातें कल्पना करने के लिए मदद कर सकता है। 100,000 उपयोगकर्ताओं का एक डाटाबेस के साथ ऊपर ACCOUNT_TYPE लेते हैं।

स्ट्रिंग enum

मान लिया जाये कि 8-बिट निश्चित लंबाई CHAR प्रकार

7*100000*8/8 = 700000 bytes 

पूर्णांक enum

मान लिया जाये कि 8-बिट TINYINT पूर्णांकों

100000*8/8 = 400000 bytes 

लगता है आकार की तरह पूर्णांक enums के साथ लगभग आधा है। इंडेक्स को समेकित करने की भी आवश्यकता है।

Answer 1

जवाब है, जैसा कि आप उम्मीद करेंगे, यह निर्भर करता है।

डाटाबेस जितना बड़ा होगा उतना ही अंतरिक्ष बचत - न केवल डिस्क पर बल्कि नेटवर्क IO और गणना में भी।

व्यक्तिगत रूप से, मैं टेक्स्ट मानों के बजाय पूर्णांक स्टोर करता हूं, जब तक कि गणना के लिए प्रत्यक्ष डीबी supprt (MySQL करता है)।

Answer 2

ints कम स्मृति ले डेटाबेस का आकार एक मुद्दा बन जाता है, तो होगा।

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

Answer 3

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

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

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

लेकिन जैसे ओदेद ने कहा - कोई भी सरल जवाब है। हर स्थिति थोड़ा अलग होगी।

Answer 4

वास्तव में, क्या आप शायद क्या करना चाहते हैं अपने डेटाबेस में एक मानचित्रण तालिका बनाने, परवाह किए बिना।
यह चीजों के एक नंबर का ख्याल रखता है -)
1 आप हमेशा की तरह एक आईडी स्तंभ दें और इसके बाद उचित कॉलम के लिए विदेशी कुंजी असाइन करें। यह बकवास मूल्यों को डालने से रोकता है। यह सामान्यीकरण के मुद्दों से भी निपटता है।
2) मानचित्रण तालिका के साथ, आप डेटाबेस-केवल चयनों को बनाने के लिए विचारों का उपयोग कर सकते हैं, जो आवश्यक टेक्स्ट स्ट्रिंग के लिए आईडी मान को आसानी से स्वैप कर सकते हैं। यह अनिवार्य रूप से सरल, वास्तव में मतलब यह नहीं है):
3) एक मानचित्रण तालिका के साथ, यह भी अंतर्राष्ट्रीयकरण मुद्दों (कृपया ध्यान से निपटने के लिए आसान हो जाता है। यहाँ कैसे मैं इस के लिए टेबल सेट अप करना होगा है:

Gender_Mapping 
Id | Enum_Mapped_Value | DBA_Readable_Description 

Gender_Description 
Id | Gender_Mapping_Id | Language_Id | Language_Specific_Description 

पुनर्प्राप्ति समस्याओं के लिए, (Enum_Mapped_Value) और (Gender_Mapping_Id, Language_Id) अद्वितीय होना चाहिए (या एक दृश्य से अद्वितीय लौट आए, कम से कम)।
Enum_Mapped_Value कुछ चरित्र कोड (शायद 5 अक्षर?) है कि डेटाबेस के लिए enum मैप करने के लिए इस्तेमाल किया जाना चाहिए। या तो सामान्य मूल्य या enum का नाम स्वयं का उपयोग करें - एक कन्स्ट्रक्टर-असाइन किए गए आंतरिक मान का उपयोग करें; अन्यथा, भविष्य के डेवलपर्स enums को पुन: व्यवस्थित कर सकते हैं, या उनका नाम बदल सकते हैं - लेकिन अंतराल मूल्यों को अकेले छोड़ने की संभावना अधिक है।
Language_Id किसी भी प्रकार की Language_Mapping तालिका के लिए एक विदेशी कुंजी के रूप में मानचित्र करना चाहिए, यदि आप कभी भी एक से अधिक भाषा से निपटने की योजना बनाते हैं।