प्रकार एक एसक्यूएल तालिका

Question

मैं एक (डमी) तालिका संरचना इस प्रकार है "स्थिति" कॉलम के लिए उपयोग करने के लिए:

 
ticket 
    id: int(11) PK 
    name: varchar(255) 
    status: ????????? 

सवाल है, क्या डेटा प्रकार मैं की स्थिति के लिए इस्तेमाल करना चाहिए? यहाँ मेरी विकल्प हैं, के रूप में मैं उन्हें देख:

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

क्या मुझे स्थिति का सटीक पठन मिला है? क्या वास्तव में एक सार्थक कुंजी है? विकल्प 4 के लिए, प्रस्तावित संरचना होगा स्थिति: चार (4) FK, जबकि यह मुझे goosebumps देता है, मैं इसे ऐसा करने के लिए किसी भी कारण से ...

अद्यतन की जरूरत नहीं है क्योंकि, एक स्थिति तालिका में। तो,

खुली => "खोलें"

CLOS => "बंद"

"PEND" => "प्राधिकरण लंबित"

"ठेला" => "प्रगति में

इस मामले में नुकसान क्या है? इस मामले में int over char का उपयोग करने का एकमात्र लाभ थोड़ा प्रदर्शन है।

Answer 1

नंबर 3 के साथ जाएं 3. एक दृश्य बनाएं जो स्थिति मान में शामिल हो यदि आप कुछ निरीक्षण करना चाहते हैं।

Answer 2

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

संपादित करें: मुझे लगता है कि यह वही है जो आपने 3 बिंदु में उल्लिखित किया है। मुझे लगता है कि यह सबसे अच्छा विकल्प है।

Answer 3

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

Answer 4

मैं नंबर 4 के साथ जाऊंगा, लेकिन मैं char(x) कॉलम का उपयोग करूंगा। यदि आप प्रदर्शन के बारे में चिंतित हैं, तो एक char (4) एक int के रूप में अधिक स्थान लेता है (और, या तो कोई सोचता है, डिस्क i/o, बैंडविड्थ, और प्रसंस्करण समय), जो स्टोर के लिए 4 बाइट भी लेता है। यदि आप प्रदर्शन के बारे में वास्तव में चिंतित हैं, तो इसे एक चार (2) या यहां तक ​​कि चार (1) बनाएं।

इसे "सार्थक डेटा" के रूप में न सोचें, इसे प्राकृतिक कुंजी के संक्षेप के रूप में सोचें। हां, डेटा का अर्थ है, लेकिन जैसा कि आपने देखा है कि डेटा के साथ काम करते समय एक अच्छी बात हो सकती है - इसका मतलब है कि आपको हमेशा से शामिल होने के लिए हमेशा शामिल नहीं होना चाहिए (भले ही छोटी छोटी तालिका में) डेटाबेस।और निश्चित रूप से विदेशी कुंजी बाधा सुनिश्चित करता है कि डेटा मान्य है, क्योंकि यह लुकअप तालिका में होना चाहिए। (यह जांच बाधाओं के साथ भी किया जा सकता है, लेकिन लुकअप टेबल आमतौर पर समय के साथ प्रबंधित और बनाए रखने के लिए आसान होते हैं।)

नकारात्मकता यह है कि आप अर्थ खोजने की कोशिश कर पकड़े जा सकते हैं। चार (1) में एक मजबूत अपील है, लेकिन यदि आप दस या अधिक मूल्य प्राप्त करते हैं, तो अच्छा सार्थक मूल्यों के साथ आने में मुश्किल हो सकती है। चार (4) के साथ एक समस्या से कम, लेकिन अभी भी एक संभावित मुद्दा है। एक और नकारात्मक पक्ष: यदि डेटा बदलने की संभावना है, तो हाँ, आपका सार्थक डेटा ("PEND" = "लंबित प्राधिकरण") इसका अर्थ खो सकता है ("PEND" = "प्रारंभिक अनुमोदन के लिए घर कार्यालय में अग्रेषित करें")। यह एक खराब उदाहरण है; यदि उस तरह के कोड बदलते हैं, तो आप व्यवसाय नियमों में बदलाव को दर्शाने के लिए अपने सिस्टम को दोबारा सुधारने से शायद बेहतर हो सकते हैं। मुझे लगता है कि मेरा बिंदु होना चाहिए, यदि यह उपयोगकर्ता द्वारा दर्ज लुकअप मान है, तो सरोगेट कुंजी (पूर्णांक) आपका मित्र होगा, लेकिन यदि वे आंतरिक रूप से परिभाषित और बनाए रखा गया है तो आपको निश्चित रूप से अधिक मानवीय अनुकूल मानों पर विचार करना चाहिए। वह, या आपको अपने मॉनिटर पर पोस्ट-एम नोट्स की आवश्यकता होगी ताकि आपको याद दिलाया जा सके कि हेक स्थिति = 31 का क्या अर्थ है। (मेरे पास तीन मिल गया है, और स्टिकम हर कुछ महीनों में पहनता है। बनाए रखने के लिए लागत के बारे में बात करें ...)

Answer 5

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

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

मजबूत - मैं "सार्थक" संक्षेपों का उपयोग करने के बारे में बहुत सावधान रहूंगा - सबसे अधिक गंभीर डेटा फाउल-अप मैंने कभी देखा है जब कोई डेवलपर कुछ डेटा साफ़ कर रहा था, और "अर्थपूर्ण" कुंजी को गलत तरीके से व्याख्या किया; पता चला है कि "PROG" का अर्थ "प्रोग्राम किया गया" नहीं है, लेकिन "प्रगति पर है"।

विकल्प 3.

Answer 6

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

विकास परिप्रेक्ष्य से, मैं प्राथमिक कुंजी के रूप में पूर्णांक जाना चाहता हूं। यदि आप जानते हैं कि यह सीमा से अधिक नहीं होगा तो आप छोटे/छोटे पूर्णांक का उपयोग कर इसे अनुकूलित कर सकते हैं।

यदि आप एक विदेशी कुंजी के रूप में संक्षेप का उपयोग करते हैं तो आपको हर बार इसे अद्वितीय बनाने के लिए सोचना होगा क्योंकि फिलिप केली ने इसका नकारात्मक हिस्सा बताया था।

आखिरकार, यदि आप चाहें तो तालिका प्रकार MYISAM घोषित कर सकते हैं।

अद्यतन: @ फिलिप केली राय को प्रतिबिंबित करते हुए, यदि बहुत अधिक स्थिति है, तो विदेशी कुंजी के रूप में पूर्णांक का उपयोग करना बेहतर है। यदि केवल कुछ ही स्थिति हैं, तो अब विदेशी कुंजी के रूप में abbr का उपयोग किया जा सकता है।