database - यवस - क्या डेटाबेस में यूएस ज़िप कोड संग्रहीत करने के लिए एक पूर्णांक कॉलम का उपयोग करना एक अच्छा विचार है?




हिंदी में डेटाबेस डिजाइन की प्रक्रिया (8)

आम तौर पर आप एक गैर-संख्यात्मक डेटाटाइप का उपयोग करेंगे जैसे कि वर्चर जो अधिक ज़िप कोड प्रकारों की अनुमति देगा। यदि आप केवल 5 अंकों [XXXXX] या 9 अंकों [XXXXX-XXXX] ज़िप कोड की अनुमति देने पर मृत सेट हैं, तो आप एक char (5) या char (10) का उपयोग कर सकते हैं, लेकिन मैं इसकी अनुशंसा नहीं करता। वर्चर सबसे सुरक्षित और सबसे अधिक पसंद है।

संपादित करें: यह भी ध्यान दिया जाना चाहिए कि यदि आप फ़ील्ड पर संख्यात्मक गणना करने की योजना नहीं बनाते हैं, तो आपको संख्यात्मक डेटा प्रकार का उपयोग नहीं करना चाहिए। ज़िप कोड इस अर्थ में एक संख्या नहीं है कि आप इसके खिलाफ जोड़ते या घटाते हैं। यह केवल एक स्ट्रिंग है जो आम तौर पर संख्याओं से बनती है, इसलिए आपको इसके लिए संख्यात्मक डेटा प्रकारों का उपयोग करने से बचना चाहिए।

पहली नज़र से, ऐसा लगता है कि डेटाबेस डेटाबेस में ज़िप कोड संग्रहीत करने के लिए मेरे पास दो बुनियादी विकल्प हैं:

  1. +4 एक्सटेंशन का समर्थन करने के लिए टेक्स्ट (शायद सबसे आम), यानी char(5) या varchar(9)
  2. संख्यात्मक, यानी 32-बिट पूर्णांक

यदि हम मानते हैं कि कोई अंतर्राष्ट्रीय चिंता नहीं है तो दोनों डेटा की आवश्यकताओं को पूरा करेंगे। अतीत में हम आम तौर पर सिर्फ पाठ मार्ग चला चुके थे, लेकिन मैं सोच रहा था कि कोई भी विपरीत करता है? संक्षेप में तुलना से यह ऐसा लगता है कि पूर्णांक विधि में दो स्पष्ट फायदे हैं:

  • यह, अपनी प्रकृति के माध्यम से, केवल संख्याओं तक ही सीमित है (जबकि सत्यापन के बिना पाठ शैली पत्रों को संग्रहीत कर सकती है और ऐसे नहीं जो मेरे ज्ञान के लिए, कभी भी ज़िप कोड में मान्य हैं)। इसका मतलब यह नहीं है कि हम सामान्य रूप से उपयोगकर्ता इनपुट को मान्य करने के लिए / चाहेंगे / चाहेंगे!
  • 5 या 9 बाइट्स के बजाय 4 बाइट्स (जो 9 अंकों के ज़िप कोड के लिए भी बहुत कुछ होना चाहिए) में कम जगह लेती है।

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

क्या ऐसी कोई चीज है जो यूएस-केवल ज़िप कोड के लिए डेटाटाइप के रूप में int का उपयोग करके हतोत्साहित करेगी?


इंटीजर अच्छा है, लेकिन यह केवल यूएस में काम करता है, यही कारण है कि ज्यादातर लोग ऐसा नहीं करते हैं। आम तौर पर मैं सिर्फ एक वर्चर (20) या तो का उपयोग करता हूं। शायद किसी भी लोकेल के लिए overkill।


क्या आप कभी भी गैर-यूएस डाक कोड स्टोर करने जा रहे हैं? कुछ पत्रों के साथ कनाडा 6 वर्ण हैं। मैं आमतौर पर सिर्फ 10 वर्ण फ़ील्ड का उपयोग करता हूं। डिस्क स्पेस सस्ता है, आपके डेटा मॉडल को फिर से काम करना है।


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

उम्मीद है की यह मदद करेगा,

बिल


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

हालांकि, संख्यात्मक प्रकारों के रूप में उन्हें संग्रहीत करने में बहुत ही वास्तविक कमी यह है कि आप आसानी से यह देखने की क्षमता खो देंगे कि डेटा गलत तरीके से दर्ज किया गया था (यानी मूल्य गुम हैं) या यदि सिस्टम संभावित शून्यों को हटा देता है जो संभावित रूप से अमान्य मान्य करने के लिए महंगा संचालन करता है ज़िप कोड जो अन्यथा सही थे।

यदि उपयोगकर्ता में से कोई एक व्यवसाय की देरी है तो सही डेटा इनपुट करने के लिए उपयोगकर्ता को मजबूर करना भी बहुत मुश्किल है। यदि उपयोगकर्ता तुरंत स्पष्ट नहीं होते हैं तो उपयोगकर्ताओं को अक्सर सही डेटा दर्ज करने का धैर्य नहीं होता है। रेगेक्स का उपयोग करना सही डेटा की गारंटी देने का एक तरीका है, हालांकि यदि उपयोगकर्ता उस मान में प्रवेश करता है जो अनुरूप नहीं होता है और उन्हें कोई त्रुटि दिखाई देती है, तो वे इस मान को पूरी तरह से छोड़ सकते हैं या कुछ ऐसा मान सकते हैं जो अनुरूप है लेकिन अन्यथा गलत है। एक उदाहरण [कनाडाई पोस्टल कोड का उपयोग करके] यह है कि आप अक्सर ए0 ए 0 ए 0 दर्ज करते हैं जो वैध नहीं है लेकिन कनाडाई पोस्टल कोड के लिए रेगेक्स के अनुरूप है। अक्सर नहीं, यह उन उपयोगकर्ताओं द्वारा दर्ज किया जाता है जिन्हें डाक कोड प्रदान करने के लिए मजबूर किया जाता है, लेकिन वे या तो नहीं जानते कि यह क्या है या यह सब सही नहीं है।

एक सुझाव यह है कि पूरे प्रविष्टि को एक इकाई के रूप में मान्य करना है जो यह सत्यापित करता है कि शेष पते की तुलना में ज़िप कोड सही है। यदि यह गलत है, तो पते के लिए वैकल्पिक मान्य ज़िप कोड की पेशकश करने से उनके लिए वैध डेटा इनपुट करना आसान हो जाएगा। इसी तरह, यदि ज़िप कोड सड़क पते के लिए सही है, लेकिन सड़क संख्या उस ज़िप कोड के डोमेन के बाहर होती है, तो उस ज़िप कोड / सड़क संयोजन के लिए वैकल्पिक सड़क संख्याएं प्रदान करें।


नहीं क्योंकि

  • आप ज़िप कोड पर गणित कार्य कभी नहीं करते हैं
  • डैश हो सकता है
  • 0 से शुरू हो सकता है
  • अंतराल जैसे स्केलर प्रकारों के मामले में कभी-कभी शून्य मानों को शून्य के रूप में व्याख्या किया जाता है (उदाहरण के लिए जब आप डेटा को किसी भी तरह निर्यात करते हैं)
  • ज़िप कोड, भले ही यह एक संख्या है, एक क्षेत्र का एक पदनाम है, जिसका अर्थ है कि यह किसी भी संख्या की संख्यात्मक संख्या के बजाय एक नाम है

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


सत्यापन के साथ एक स्ट्रिंग का प्रयोग करें। ज़िप कोड 0 से शुरू हो सकते हैं, इसलिए संख्यात्मक एक उपयुक्त प्रकार नहीं है। साथ ही, यह अंतर्राष्ट्रीय डाक कोड (जैसे यूके, जो 8 अक्षरों तक है) के लिए अच्छी तरह से लागू होता है। संभावित मामले में डाक कोड एक बाधा हैं, आप इसे 10 वर्णों तक सीमित कर सकते हैं, लेकिन पहले अपने लक्षित प्रारूपों को देखें

यूके, यूएस और कनाडा के लिए सत्यापन पुनर्जन्म यहां दिए गए हैं

हां, आप अग्रणी शून्य वापस पाने के लिए पैड कर सकते हैं। हालांकि, आप सैद्धांतिक रूप से जानकारी को फेंक रहे हैं जो त्रुटियों के मामले में मदद कर सकता है। अगर किसी को डेटाबेस में 1235 मिलते हैं, तो क्या वह मूल रूप से 01235 है, या कोई अन्य अंक याद किया गया है?

सर्वश्रेष्ठ अभ्यास कहता है कि आपको कहना चाहिए कि आपका क्या मतलब है। एक ज़िप कोड एक कोड है, संख्या नहीं। क्या आप ज़िप कोड add/subtract/multiply/divide करने जा रहे हैं? और व्यावहारिक परिप्रेक्ष्य से, यह अधिक महत्वपूर्ण है कि आप विस्तारित ज़िप को छोड़ रहे हैं।







postal-code