एक डेटाबेस (RDBMS) में डाक पते संग्रहीत करने के लिए सर्वोत्तम अभ्यास?

Question

आरडीबीएमएस में डाक पते के भंडारण के लिए सर्वोत्तम प्रथाओं के लिए कोई अच्छा संदर्भ हैं? ऐसा लगता है कि बहुत सारे ट्रेडऑफ़ हैं जिन्हें बनाया जा सकता है और प्रत्येक के मूल्यांकन के लिए बहुत सारे पेशेवरों और विपक्षों को - निश्चित रूप से यह समय और समय फिर से किया गया है? हो सकता है कि किसी ने कम से कम कुछ सीखे हुए पाठ कहीं लिखे हों?

मैं जिस ट्रेडऑफ़ के बारे में बात कर रहा हूं उसके उदाहरण एक पूर्णांक बनाम एक चार फ़ील्ड के रूप में जिपकोड को संग्रहीत कर रहे हैं, क्या मकान नंबर को एक अलग फ़ील्ड या एड्रेस लाइन 1 के हिस्से के रूप में संग्रहीत किया जाना चाहिए, सूट / अपार्टमेंट / आदि संख्याओं को सामान्यीकृत किया जाना चाहिए या बस के रूप में संग्रहीत किया जाना चाहिए पता पंक्ति 2 में पाठ का हिस्सा, आप ज़िप +4 (अलग फ़ील्ड या एक बड़ा फ़ील्ड, पूर्णांक पाठ) कैसे संभालते हैं? आदि।

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

Comments

बैट जिप के ठीक बाहर एक चार क्षेत्र होना चाहिए - अन्यथा निश्चित ज़िपकोड जो 0 से शुरू होता है, गलत हो जाएगा।

— मेनाशेह

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

— ज़िकैटो

Answer 1

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

यहां मॉड्यूल पृष्ठ से कॉपी किए गए स्कीमा का सार है:

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

एक सबक जो मैंने सीखा है:

• संख्यात्मक रूप से कुछ भी संग्रहीत न करें।
• देश और प्रशासनिक क्षेत्र को आईएसओ कोड के रूप में स्टोर करें जहां संभव हो।
• जब आप नहीं जानते हैं, तो खेतों की आवश्यकता के बारे में शिथिल रहें। कुछ देश आपके द्वारा लिए गए फ़ील्ड का उपयोग नहीं कर सकते हैं, यहां तक ​​कि बुनियादी चीजें जैसे locality& thoroughfare।

Comments

क्या मैं पूछ सकता हूं कि "name_line" का उद्देश्य क्या है? मुझे वास्तव में Drupal Docs या xNal Standard में स्पष्टीकरण नहीं मिला। मैं इसे कैसे समझता हूं name_line मेल द्वारा वास्तविक पत्र या पार्सल भेजने के लिए है। First_name / last_name केवल यदि आप ईमेल द्वारा सीधे ग्राहक को संबोधित करने, जैसे चाहते हैं की जरूरत है ( "प्रिय मिस्टर <last_name>")। या इसका कोई अन्य उद्देश्य / लाभ है?

— 16

(बड़े) वाणिज्यिक परिसर में पहुंचाने के लिए, आंतरिक डाक वितरण प्रणाली के लिए एक नाम अक्सर आवश्यक होता है (मेल रूम वाले कार्यालय भवनों पर विचार करें)

— क्रिस ब्राउन

पता फील्ड ने ले लिया है पता । ऐसा लगता है कि खेत कुछ अलग हो सकते हैं

— गेविन हेन्स

Answer 2

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

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

मैं सलाह देता हूं कि ~ चर-लंबाई की 10 पंक्तियां, एक साथ एक पिनकोड के लिए एक अलग क्षेत्र के साथ (और सावधान रहें कि आप कैसे वर्णन करते हैं कि राष्ट्रीय संवेदनाओं से निपटने के लिए)। उपयोगकर्ता / ग्राहक को अपने पते लिखने का निर्णय लेने दें।

Comments

इसके लायक क्या है, यह एक वेब साइट के लिए नहीं है, लेकिन अंतरराष्ट्रीय पतों के बारे में अभी भी अच्छी तरह से लिया गया है।

— जॉन

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

— बेनालास्टर

Answer 3

यदि आपको इस बारे में व्यापक जानकारी की आवश्यकता है कि अन्य देश डाक पते का उपयोग कैसे करते हैं, तो यहां एक बहुत अच्छा संदर्भ लिंक (कोलंबिया विश्वविद्यालय) है:

फ्रैंक के लिए अनिवार्य गाइड पोस्टल पते इंटरनेशनल मेल के लिए प्रभावी पते

Answer 4

आपको निश्चित रूप से "आधा-संख्या", या मेरे वर्तमान पते जैसे विशेष मामलों की वजह से एक संख्या के बजाय एक चरित्र क्षेत्र के रूप में घर के संचय पर विचार करना चाहिए, जो कि "129A" ​​जैसा कुछ है - लेकिन ए को अपार्टमेंट के रूप में नहीं माना जाता है वितरण सेवाओं के लिए नंबर।

Answer 5

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

मैं नॉर्वेजियाई डाक कोड (मुझे लगता है) के साथ कुछ मुद्दे को याद करता हूं, जो ओस्लो को छोड़कर सभी 4 स्थान थे, जिसमें 18 या तो थे।

मुझे यकीन है कि इस समय से हमने अपने सभी राष्ट्रीय पतों के लिए भौगोलिक रूप से सही ज़िप कोड का उपयोग करना शुरू कर दिया था, काफी लोगों ने शिकायत करना शुरू कर दिया कि उनका मेल बहुत देर से आया। पता चला कि वे लोग डाक क्षेत्रों के बीच एक सीमा रेखा के पास रह रहे थे, और इस तथ्य के बावजूद कि कोई व्यक्ति वास्तव में डाक क्षेत्र में रहता था, कहते हैं, 1600, वास्तव में उसके मेल को डाक क्षेत्र 1610 को संबोधित किया जाना चाहिए, क्योंकि वास्तव में यह पड़ोसी डाक क्षेत्र था वास्तव में उसकी सेवा की है, इसलिए अपने डाक को सही डाक क्षेत्र में भेजने से उस डाक को आने में कुछ दिनों का समय लगेगा, क्योंकि अवांछित डाकघर को गलत डाक क्षेत्र में इसे आगे भेजने के लिए आवश्यक अवांछित हस्तक्षेप की वजह से था ...

(हमने आईएसओ-कोड 'ZZ' के साथ देश में विदेश में एक पते के साथ उन लोगों का पंजीकरण समाप्त किया।)

Answer 6

आपको निश्चित रूप से " एक संबंधपरक डेटाबेस में पता जानकारी को मॉडल करने के लिए यह एक अच्छा तरीका है " से परामर्श करना चाहिए , लेकिन आपका प्रश्न इसका प्रत्यक्ष डुप्लिकेट नहीं है।

निश्चित रूप से बहुत सारे पहले से मौजूद उत्तर हैं (उदाहरण के लिए, डेटाबेस सर्वर पर उदाहरण डेटा मॉडल देखें)। पहले से मौजूद कई उत्तर कुछ परिस्थितियों में खराब हो जाते हैं (डीबी उत्तर पर बिल्कुल नहीं चुनना)।

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

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

Answer 7

जब तक आप सड़क संख्या या ज़िप / डाक कोड पर गणित करने जा रहे हैं, आप केवल संख्या विज्ञान के रूप में संग्रहीत करके भविष्य के दर्द को आमंत्रित कर रहे हैं।

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

डिस्क स्पेस की लागत बाद में इसे ठीक करने की लागत से बहुत सस्ता होने जा रहा है ... y2k कोई भी?

Answer 8

क्या @ को जोड़ना जोनाथन Leffler और @ पॉल फिशर ने कहा है

यदि आप कभी भी अपनी आवश्यकताओं में कनाडा या मैक्सिको के लिए डाक पते होने का अनुमान लगाते हैं, तो postal-codeस्ट्रिंग के रूप में भंडारण करना आवश्यक है। कनाडा में अल्फा-न्यूमेरिक पोस्टल कोड हैं और मुझे याद नहीं है कि मेरे सिर के ऊपर से मेक्सिको की तरह क्या दिखता है।

Answer 9

Ive ने पाया कि सबसे छोटी असतत इकाई से लेकर सबसे बड़े तक सभी संभावित क्षेत्रों को सूचीबद्ध करना सबसे आसान तरीका है। उपयोगकर्ता उन फ़ील्ड को भरेंगे जिन्हें वे फिट देखते हैं। मेरी पता तालिका इस प्रकार है:

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

Comments

पीओ बॉक्स कैसे स्टोर करते हैं?

— जौन

बस एक और कॉलम जोड़ें PO_box यदि आपको यह पूर्वव्यापी रूप से करना है, तो इसका मतलब है कि पिछले पते में से एक को पीओ बॉक्स की आवश्यकता है, इसलिए इसे शून्य पर सेट किया जा सकता है

— Gaz_Edge

Answer 10

नंबर को NUMBER या VARCHAR के रूप में संग्रहीत करने में "व्यापार बंद" कहां है? यह सिर्फ एक विकल्प है - यह एक व्यापार बंद नहीं है जब तक कि दोनों के लिए लाभ नहीं हैं और आपको दूसरों को पाने के लिए कुछ लाभ छोड़ना होगा।

जब तक ज़िप के योग का कोई मतलब न हो, संख्या के रूप में ज़िप उपयोगी नहीं है।

Comments

एक ट्रेडऑफ़ डेटाबेस आकार हो सकता है। Mysql 5 में, एक मध्यम पंक्ति में केवल 3 बाइट्स प्रति पंक्ति होगी जबकि एक varchar (5) दो बार उतना ही लेगा। मैंने यह भी सोचा था कि संख्यात्मक खोजें पाठ की तुलना में तेज़ थीं, लेकिन मैं उस पर सकारात्मक नहीं हूं।

— gpojd

एक चरचर का उपयोग करना चाहिए। कैनेडियन पोस्टल कोड एक अल्फा न्यूमेरिक एन्कोडिंग का उपयोग करता है, जो एक संख्या में अच्छी तरह से फिट नहीं होगा।

— EvilTeach

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

— rinogo

@ वर्नोगो ने varchar का उपयोग करने के लिए एक तर्क यह दिया है कि ज़िप कोड गणितीय अर्थों में संख्यात्मक नहीं हैं; इससे उन्हें जोड़ने या घटाने का कोई मतलब नहीं है; वे केवल एक प्रतिबंधित चरित्र सेट के साथ एन्कोडेड हैं। stackoverflow.com/a/893489/48659

— स्टीव फोली

@SteveFolly और स्ट्रिप होने के कारण ज़िप कोड के आगे समर्थन में, प्रमुख पात्रों का विशेष महत्व है: en.wikipedia.org/wiki/ZIP_Code#Primary_state_prefixes यदि कोई तर्क लागू करने जा रहा है जैसे "मूल्य के बाएं-सबसे वर्ण हैं ? " तब यह सुनिश्चित होता है कि पूर्णांक की तुलना में यह एक स्ट्रिंग की तरह लगता है।

— डेविड एल्ड्रिज

Answer 11

यह एक ओवरकिल हो सकता है, लेकिन अगर आपको एक समाधान की आवश्यकता है जो कई देशों के साथ काम करेगा और आपको प्रोग्राम के पते के कुछ हिस्सों को संसाधित करने की आवश्यकता होगी:

आपके पास दो तालिकाओं का उपयोग करते हुए देश विशिष्ट पता हो सकता है: 10 VARCHAR2 कॉलम, 10 संख्या स्तंभों के साथ एक सामान्य तालिका, एक अन्य तालिका जो इन क्षेत्रों को संकेत देती है और एक देश स्तंभ एक देश के लिए एक पते की संरचना बांधती है।

Comments

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

— एंड्रयू स्टिट्ज

Answer 12

यदि आपको कभी भी किसी पते को सत्यापित करना है या क्रेडिट कार्ड से भुगतान करने की प्रक्रिया का उपयोग करना है, तो आपको कम से कम संरचना की आवश्यकता होगी। पाठ का एक फ़्री-फ़ॉर्म ब्लॉक उसके लिए बहुत अच्छा काम नहीं करता है।

जिप कोड पूरे पते का उपयोग किए बिना भुगतान कार्ड लेनदेन को मान्य करने के लिए एक सामान्य वैकल्पिक क्षेत्र है। तो उस (कम से कम 10 वर्णों) के लिए एक अलग और उदार आकार का क्षेत्र रखें।

Answer 13

डेटाबेस उत्तर से प्रेरित

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Answer 14

मैं बस सभी बड़े क्षेत्रों को एक साथ एक बड़े NVARCHAR (1000) क्षेत्र में रखूँगा, जिसमें उपयोगकर्ता के लिए एक textarea तत्व होगा, जिसके लिए मान दर्ज करना होगा (जब तक कि आप उदाहरण के लिए विश्लेषण नहीं करना चाहते। ज़िप कोड)। उन सभी पता पंक्ति 1, पता पंक्ति 2, आदि इनपुट सिर्फ इतने कष्टप्रद हैं यदि आपके पास एक पता है जो उस प्रारूप के साथ अच्छी तरह से फिट नहीं है (और, आप जानते हैं, यूएस के अलावा अन्य देश हैं)।

Comments

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

— एंड्रयू स्टिट्ज

कौन सी गड़बड़? आपको डेटा के लिए क्या चाहिए? अक्सर आपको इसे केवल कुछ लेबल प्रिंटर या इसके समान सीधे पास करने की आवश्यकता होती है, और फिर आप इसे केवल पाठ की एक बूँद के रूप में मान सकते हैं। अन्य बार आप शहरों और ज़िप कोड के बारे में परवाह कर सकते हैं (लेकिन आप बेहतर यह सुनिश्चित करते हैं कि आपके पास केवल समर्थित देशों में ग्राहक हैं)

— erikkallen

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

— एंड्रयू स्टिट्ज़

यदि आपको बाद में पता चलता है कि आपको डेटा के टुकड़े की आवश्यकता नहीं थी, तो आप इसे बाद में "नष्ट" कर सकते हैं। "डेटा बनाना", दुःस्वप्न (अलग-अलग क्षेत्रों में जानकारी को विभाजित करना) से लेकर असंभव (तथ्य के बाद डेटा को कैप्चर करना) तक है। यदि ओपी ने कहा था, "केवल इसे लेबल प्रिंटर को भेजने की आवश्यकता है" तो मैंने आपके उत्तर की सराहना की और मतदान किया। हालांकि, ऐसा कुछ विशिष्ट उल्लेख किए बिना कि डेटा को नष्ट करने का एक सुझाव, आईएमओ, गैर-जिम्मेदार या यहां तक ​​कि मतलब की कगार पर है।

— एंड्रयू स्टीट्ज

जहां मैंने काम किया है (ज्यादातर ई-कॉमर्स), हम इसे 5-6 अलग-अलग क्षेत्रों में संग्रहीत करते हैं, लेकिन हम कभी भी, कभी भी, डिलीवरी को भेजने के लिए उपयोग करने के अलावा अन्य जानकारी के साथ कुछ भी नहीं करते हैं।

— एरिकक्लेन