2009-04-14 13 views
22

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

मैं YetAnotherAddressBook निर्माण कर रहा हूँ और वहाँ एक पोस्ट कोड क्षेत्र है कहो। बशर्ते कि डाक कोड हमेशा एक 4 अंकों की संख्या है, मैं इसे किस डेटा प्रकार के रूप में संग्रहीत करता हूं? पूर्णांक या स्ट्रिंग? तकनीकी रूप से यह एक पूर्णांक है, लेकिन मैं इस पर किसी प्रकार की गणना नहीं कर रहा हूं, मैं बस इसे एक टेबल में थूक रहा हूं। अगर मैं पोस्ट कोड द्वारा टेबल को सॉर्ट करना चाहता हूं तो क्या आपकी राय बदल जाएगी?

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

+4

और हाँ। मैंने वास्तविक प्रश्न –

उत्तर

36

मेरे देश में, पोस्ट-कोड भी हमेशा 4 अंक होते हैं। लेकिन पहला अंक शून्य हो सकता है।

यदि आप की दुकान "0700" एक पूर्णांक के रूप में, आप समस्याओं का एक बहुत कुछ प्राप्त कर सकते हैं:

  • इसे सही ढंग से दशमलव मान के रूप में पढ़ा जाता है, तो यह एक ऑक्टल मान
  • रूप में पढ़ा जा सकता है, यह "700"
  • जब आपको "700" मान मिलता है, तो आपको शून्य
  • जोड़ना याद रखना चाहिए, मैं शून्य नहीं जोड़ता, बाद में, आपको कैसे पता चलेगा कि "700" है " 0700 ", या किसी ने" 7100 "गलत टाइप किया?

तकनीकी रूप से, हमारे पोस्ट कोड वास्तव में तार हैं, भले ही यह हमेशा 4 अंक हों।

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

लेकिन कितने फ़ाइलों को एक धार में संग्रहीत करने के बारे में क्या है? इंटीजर या स्ट्रिंग?

यह स्पष्ट रूप से एक पूर्णांक है।

+0

लिखने के बजाय लिंक स्वरूपित करने में अधिक समय व्यतीत किया है, मुझे लगता है कि यह एप्लिकेशन पर निर्भर करता है, अगर आप एक दूसरे से अधिक इस्तेमाल करते हैं तो आपको क्या लाभ मिलेगा। मैं स्टोर नंबरों का उपयोग करता हूं, वे संख्यात्मक हैं, लेकिन वास्तव में वे एक स्ट्रिंग हैं क्योंकि "00004" मैं इसे आउटपुट स्वरूपित किए बिना इसे इस तरह रखना चाहता हूं जब मैं इसे मानव पठनीय बनाना चाहता हूं। जब मैं इसे सहेजता हूं, तो मैं इसे मान्य करता हूं कि यह संख्यात्मक है, फिर इसे स्ट्रिंग के रूप में सहेजें। मेरा नुकसान भंडारण आकार की संभावना अधिक होगी, और चूंकि मेरे पास फ़ील्ड पर एक इंडेक्स है, इसलिए इसका थोड़ा खराब प्रदर्शन हो सकता है लेकिन मैं इसके बारे में 100% नहीं हूं। – radtek

0

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

नीचे पंक्ति - यदि आप इस पर अंकगणित नहीं करते हैं, तो शायद यह वास्तव में एक संख्या नहीं है।

2

डाक कोड के लिए मैं एक स्ट्रिंग चुनूंगा। यह आंतरिक रूप से एक पूर्णांक नहीं है। यह सिर्फ कुछ के लिए एक पहचानकर्ता है और यह चार पात्रों की श्रृंखला भी हो सकता है।

एक धार के अंदर फ़ाइलों की संख्या के लिए, यह एक पूर्णांक होना चाहिए।

2

'0000' एक पोस्टकोड है? क्या यह '0' से अलग है?

यदि यह हमेशा चार अंक संख्या है, तो मैं इसे हमेशा 4 अंकों के रूप में संग्रहीत करता हूं, और यह इसे एक स्ट्रिंग के रूप में रखने के लिए इंगित करेगा।

10

डाक कोड के लिए मेरी राय में आपको स्ट्रिंग का उपयोग करना होगा, क्योंकि आपके पास शून्य कोड (0 9 100) के साथ डाक कोड हो सकते हैं और यदि आप पूर्णांक का उपयोग करते हैं तो यह 9100 होगा: सॉर्टिंग कोई समस्या नहीं है, क्योंकि अभी भी एक समस्या है वर्णमाला क्रम ('09100' '09101' से पहले आता है)। फ़ाइल नंबरों को संग्रहीत करने के लिए मैं एक इंटरगर की अपेक्षा करता हूं, इसलिए आपको इसकी संख्या को कम करने/घटाने में कोई समस्या नहीं है। तो पूर्णांक बनाम तार आपके द्वारा उपयोग किए जाने वाले उपयोग पर निर्भर करता है!

9

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

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

1

मैं संख्यात्मक डेटा प्रकार का उपयोग नहीं करता जब तक कि मैं डेटा पर गणित करने की अपेक्षा नहीं करता। भविष्य में किसी समस्या के लिए किसी समस्या को खोजने का जोखिम क्यों है, जिसे आप "निश्चित" थे, हमेशा एक संख्या होगी जो कोई गैर-अंकीय चरित्र डालने का निर्णय लेता है।

यदि आप इसे गणित करने वाले नहीं हैं एक स्ट्रिंग।

0

महत्वपूर्ण निर्धारक, इमहो, यह है कि क्या उपकरण को मूल्यों पर संख्यात्मक अंकगणितीय गणना करने की आवश्यकता होगी, यदि नहीं, तो पूर्णांक का उपयोग करने का एकमात्र कारण भंडारण आवश्यकताओं को कम करना है, (जो "मई" महत्वपूर्ण हो सकता है एक महत्वपूर्ण अनुप्रयोग में प्रदर्शन - सूचकांक प्रदर्शन को बढ़ाने के लिए तालिका सूचकांक की चौड़ाई को कम करके, उदाहरण के लिए) लेकिन अन्यथा, आम तौर पर महत्वपूर्ण नहीं है ...

यदि मूल्यों के साथ अंकगणित करने की कोई आवश्यकता नहीं है, तो एक स्ट्रिंग श्रेष्ठ है।

5

पोस्ट कोड एक संख्या नहीं है: यह एक कोड या पहचानकर्ता है। यह फोन नंबर पर लागू होता है।

धार में फ़ाइलों की संख्या एक पूर्णांक है।

कम से कम, इस मामले में आप डेटाबेस स्तर पर डेटा को सही रखने के लिए CHECK CONSTRAINT LIKE '[09][09][09][09]' बना सकते हैं।

1

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

यह एक पूर्णांक या अन्य संख्यात्मक डेटा प्रकार है:

28

मैं हमेशा निम्नलिखित नियम का उपयोग करें।

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

ज़िप कोड के उदाहरण में, आपके पास कभी ऐसा समय नहीं होना चाहिए जहां आपको ज़िप कोड में जोड़ने की आवश्यकता हो, या घटाएं, या दो ज़िप कोड एक साथ गुणा करें। गणितीय कार्यों का आमतौर पर ज़िप कोड पर उपयोग नहीं किया जाता है क्योंकि इन्हें पहचानकर्ता के रूप में उपयोग किया जाता है, मात्रा नहीं। इसलिए यदि आप एक स्ट्रिंग डेटाप्रकार के रूप में अपने ज़िप कोड संग्रहीत करना चाहिए

+1

मैं पूरी तरह से सहमत हूं और उस तर्क का भी उपयोग करता हूं। +1 – Cerebrus

6

खैर जहाँ तक डाक कोड का सवाल है, यह एक ठेठ ब्रिटेन पोस्टकोड है:

EC2R 6PK 

विश्वविद्यालय में मेरी डेटाबेस व्याख्याता मुझे कुछ बताया कि मेरे साथ अटक गया है और अभी भी 15+ साल बाद है:

यदि आप इस पर अंकगणित करते हैं, तो को एक संख्या के रूप में स्टोर करें। अन्यथा यह स्ट्रिंग है।

सचमुच मुझे नहीं लगता कि आप उस सलाह के साथ गलत हो सकते हैं।

स्पष्ट रूप से आप पोस्टकोड पर अंकगणित नहीं करते हैं, इसलिए वे तार हैं।

+0

यदि आप क्षेत्र को इंडेक्स करते हैं तो पोस्टग्रेज़/माइस्क्ल या यहां तक ​​कि मोंगोडब नोस्कल डीबी जैसे रिलेशनल डेटाबेस में, char over index का उपयोग करते समय कोई प्रदर्शन प्रभाव होगा? जो कुछ मैं उलझन में हूँ। – radtek

0

सोमटाइम्स "हमेशा" का मतलब है "अगले महीने के लिए"। मैं 4 अंकों के कोडों पर गिनती नहीं करूंगा जो मेरी ज़िम्मेदारी के जीवन में अल्फान्यूमेरिक नहीं जा रहे हैं।

एसक्यूएल की कुछ बोलीयां एक डेटाटाइप का समर्थन करती हैं जो NUMBER (4) की तरह है। यह एक वर्ण स्ट्रिंग की तरह काम करता है, लेकिन वर्णमाला 0 से 9 0 है।

0

मुझे एक ज़िप कोड को एक संख्या के रूप में संग्रहीत करने में कोई समस्या नहीं है, भले ही आप उस पर गणित संचालन करने की अपेक्षा न करें।

हमारे कॉर्पोरेट डेटा गोदाम में, हम कई विरासत प्रणालियों से डेटा प्राप्तकर्ता हैं। नतीजतन, हम बहुत सारे कचरा डेटा का उपयोग किया जा रहा है।

हमारे मामले को ले जाएं जहां हमारे पास एक भौगोलिक पहचानकर्ता है जो एक शून्य भरा 4-अंकीय "संख्यात्मक" मान है। इस क्षेत्र को अक्सर तालिकाओं में शामिल होने के लिए प्रयोग किया जाता है।

मैं दो तरीकों में से एक ले जाएगा: 1) लंबाई 4 के एक क्षेत्र के रूप में चार स्तंभ घोषित करने और जोड़ने की कोई समस्या की तरह '[09] [09] [09] [09]' 2) के रूप में यह परिभाषित एक संख्यात्मक लंबाई 4 और, यदि उपयोगकर्ता इसे चाहते हैं, तो केवल प्रदर्शित होने पर मान को प्रारूपित करें।

दृष्टिकोण संख्यात्मक 1 आपको लगातार स्वरूपण की परेशानी बचाता है, जो कोई बड़ा सौदा नहीं है, लेकिन यदि आप प्रायः फ़िल्टरिंग और यहां तक ​​कि अनुक्रमणित/कॉलम पर शामिल होते हैं, तो मैं यह कहने पर विचार करता हूं कि हम विकल्प # 2 के साथ बंद हैं ।

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

नतीजतन, हमारे डेटा वेयरहाउस शून्य के साथ असंगत पूर्व-भरने या मूल्य के औचित्य सहित सभी प्रकार के विविधताओं को प्राप्त करने के समाप्त होता है।

जब आप किसी इंटेग्रर के रूप में कुछ परिभाषित करते हैं, तो आप स्वचालित रूप से अधिक कुशल संग्रहण प्राप्त करते हैं, esp। कॉलम पर अनुक्रमण करते समय, और संपादित करें और जो सभी समझते हैं और विभिन्न क्षमताओं के डेटाबेस डिजाइनरों द्वारा विरासत प्रणाली में निरंतर लागू होने की अधिक संभावना है।

मुझे इंडेक्स में फ़ील्ड का उपयोग करने के अपवाद के साथ विकल्प # 1 के साथ कोई समस्या नहीं है और एक बार जब आप एक फ़ील्ड को अपहा अंक के रूप में स्वीकार करते हैं, तो इस दृष्टिकोण पर मेरी चिंता है, लोग इसमें अधिक जंक फेंकते हैं।

उदाहरण के लिए, हमारे पीपुल्सॉफ्ट कर्मचारी पहचानकर्ता को लें। किसी ने कर्मचारी को ठेकेदार होने के लिए नामित करने के लिए कर्मचारी 6-चार शून्य भरे "नंबर" के सामने "एक्स" जोड़ने का निर्णय लिया। यह मेरे व्यक्तिगत अभ्यास का उल्लंघन करता है न कि सूचना के अलग-अलग टुकड़ों को एक ही क्षेत्र में जोड़ना। इससे विभिन्न प्रणालियों में असंगतता की सभी प्रकार की समस्याएं हुईं। यदि यह क्षेत्र एक संख्यात्मक था, तो कोई भी ऐसा करने की कोशिश नहीं करता।

टिप्पणियां?

0

आपके द्वारा काम कर रहे डेटा के अर्थशास्त्र को समझना हमेशा महत्वपूर्ण होता है। मुझे इसे उदाहरण पर समझाएं।

विचार करें कि आप अपने डेटाबेस में पिन स्टोर करना चाहते हैं। जवाब देने के लिए आपको किस डेटाटाइप का उपयोग करना चाहिए, आपको जवाब देना होगा कि पिन (Personal identification number) वास्तव में क्या मतलब है।

  1. तो यह वास्तव में एक संख्या है जैसा कि इसके नाम को सही मायने में इंगित करता है तो मैं किसी भी कारण है कि यह एक पूर्णांक के रूप में प्रतिनिधित्व नहीं किया जाना चाहिए नहीं दिख रहा।

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

    नोट: यदि पिन की लंबाई को 4 अंकों के बारे में बताए जाने के लिए तय किया जाएगा तो वे अभी भी पूर्णांक का उपयोग कर सकते हैं क्योंकि कोई भी संख्या हमेशा प्रमुख शून्य से भर जाएगी और बिल्कुल वही मायने रखेगी (0001 01 जैसा ही होगा) - लेकिन गलत इनपुट से बचने के लिए इन निश्चित लंबाई प्रतिबंध संख्याओं के लिए विशिष्ट हैं।

  2. यदि अर्थशास्त्र स्पष्ट रूप से बताता है कि पिन एक संख्या है, यानी, पिन 0001 पिन 01 के समान है, तो मैं एक पूर्णांक प्रतिनिधित्व का उपयोग करूंगा।

इसलिए आपके मामले में postal code अर्थशास्त्र को समझना महत्वपूर्ण है। यह अर्थशास्त्र अलग-अलग देशों में भिन्न हो सकता है (या समय के साथ भी बदल सकता है) इसलिए यह भी महत्वपूर्ण है कि आप इसका उपयोग करना चाहते हैं। सभी प्रकार के पोस्टल कोड और यहां तक ​​कि संभावित परिवर्तनों को कवर करने के लिए मैं अधिक अमूर्त डेटा प्रकार या केवल एक स्ट्रिंग का उपयोग करने पर विचार करता हूं (मुझे विश्वास है कि पहले से ही अर्थशास्त्र हैं जिनमें केवल अंकों की तुलना में अधिक वर्ण हैं)।

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

आपके पास डेटा है और आप इसे स्टोर करना चाहते हैं, इसे किसी भी तरह से प्रस्तुत करें - बस इस बारे में सोचें कि आप किसके साथ काम कर रहे हैं।

संबंधित मुद्दे