क्या दुनिया के सभी पतों के लिए कॉमन स्ट्रीट एड्रेस डेटाबेस डिजाइन है?


122

मैं एक प्रोग्रामर हूं और ईमानदारी से कहूं तो दुनिया की स्ट्रीट एड्रेस स्ट्रक्चर्स का पता नहीं है, बस मेरे देश में कैसे स्ट्रक्चर्ड है :) इसलिए स्ट्रीट एड्रेस स्टोर करने के लिए सबसे अच्छा और कॉमन डेटाबेस डिजाइन कौन सा है? यह उपयोग करने के लिए बहुत सरल होना चाहिए, दुनिया के सभी सड़क पतों को संग्रहीत करने के लिए तेजी से क्वेरी और डायनेमिक करने के लिए जो केवल एक आईडी द्वारा पहचान कर रहा है
धन्यवाद



आपने सड़क के पते के बारे में पूछा, लेकिन सभी उत्तर डाक पते ( अंतर क्या है? ) के बारे में हैं। शायद शीर्षक बदलना चाहिए?
wrygiel

जवाबों:


123

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

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

पतों को संग्रहीत करने के लिए एक उचित प्रारूप निम्नानुसार होगा:

  • पता लाइन्स 1-4
  • इलाका
  • क्षेत्र
  • पोस्टकोड (या ज़िपकोड)
  • देश

पता लाइनें 1-4 घटक पकड़ सकते हैं जैसे:

  • इमारत
  • उप-बिल्डिंग
  • परिसर संख्या (मकान संख्या)
  • परिसर की सीमा
  • मार्ग
  • उप-आम रास्ते का
  • डबल-निर्भर क्षेत्र
  • उप-इलाका

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

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

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


1
क्या आप UPU के लिए URL दे सकते हैं? (हाँ, मुझे पता है कि मैं इसे पा सकता था - लेकिन सबसे अच्छे उत्तर लोगों को खोज नहीं करते।)
जोनाथन लेफ़लर

प्रयास करें upu.int/post_code/en/... और में ड्रॉप-डाउन उपयुक्त देश चुनें
barrowc

यूपीयू पोस्ट * कोड उत्पाद के लिए URL जोड़ा गया
एडवर्ड रॉस

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

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

47

डेटाबेस उत्तर पर एक नजर है । विशेष रूप से, यह कई मामलों को कवर करता है:

(सभी चर लंबाई वर्ण डेटाटाइप)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

यहाँ छवि विवरण दर्ज करें


मैं नीचे नहीं गया, लेकिन मुझे लगता है कि यह एकमात्र तरीका है कि यह काम कर सकता है अगर सभी फ़ील्ड लेकिन एड्रेसआईडी और लाइन 1 वैकल्पिक थे। किस मामले में, यह बहुत उपयोगी नहीं है।

11
डेटा प्रकार महत्वपूर्ण हैं - हर देश में पूर्णांक ज़िप कोड नहीं हैं! एक सहकर्मी को कनाडा में एक ग्राहक के साथ यह पता चला।
एरिक

1
@ ईरिक: ईद से इतर उन सभी क्षेत्रों में चरित्र चित्रण हैं
मिच गेहूं

2
देश आईडी के लिए, आपको आईएसओ 3166 2-अक्षर (या 3-अक्षर) देश कोड का उपयोग करना चाहिए। प्रस्तावित स्कीमा आपको विश्लेषण किए गए पते को संग्रहीत करने की अनुमति देता है; यह आपको यह नहीं बताता कि इसे कैसे प्रारूपित किया जाए। (ओह, और यूके में अल्फ़ान्यूमेरिक पोस्ट कोड हैं - IP31 3GH, SE1W 9PQ, आदि मुझे लगता है कि दूसरा समूह हमेशा NAA है; पहला समूह A से शुरू होता है और इसमें कम से कम एक N (A = अल्फ़ा, N = अंक) होता है; लेकिन मुझे कुछ भी आश्चर्य नहीं होगा।)
जोनाथन लेफ़लर

@ नील: बिल्कुल। देश में इतनी भिन्नता है कि आप किसी एक तालिका का उपयोग नहीं कर सकते हैं और db से इसे सत्यापित करने की अपेक्षा करते हैं।
डेव शेरोमैन

26

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

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


समझ में आता है। मैं इस समस्या का एक अच्छा समाधान खोज रहा हूं लेकिन कई अलग-अलग हैं। जैसा आपने कहा: वास्तविक आवश्यकताओं में से चुना जाना शायद सबसे अच्छा है।
डिस्प्लेनाम

12

कभी-कभी किसी गली के पते पर आप निकटतम शहर को देख सकते हैं।

मेरे पास एक बार भारत के सभी माध्यमिक विद्यालयों को Google मानचित्र में रखने का प्रोजेक्ट था। मैंने Google API का उपयोग करके एक स्पिफ़ी प्रोग्राम लिखा और सोचा कि यह काफी आसान होगा।

फिर मुझे क्लाइंट से डेटा मिला। कुछ स्कूल के पते "बाजार के उस पार, नाई के बगल में" या "पुराने बस स्टैंड के पास" जैसी चीजें थीं।

इसने मेरे काम को बहुत कठिन बना दिया है, दुर्भाग्य से, Google एपीआई उस प्रारूप का समर्थन नहीं करता है।


2
एशियाई पते इसके लिए भी कुख्यात हैं। "73 वां ब्लॉक पश्चिम निन्जांग सेंट, बिल्डिंग 2, दूसरा ऊपरी लिफ्ट लें, फूड कोर्ट के बगल में कार्यालय परिसर, 468 वां औद्योगिक जिला, शंघाई 456789" ...
ruhnet

9

अंतरराष्ट्रीय पतों के लिए, यदि यह खेतों में टूट गया है तो जानकारी को प्रारूपित करने का एक तरीका खोजना काफी कठिन है। उदाहरण के लिए, एक इतालवी पता उपयोग करता है:

<street address>
<zip> <town> <region>
<country>

जैसे कि

Via Eroi della Repubblica
89861 Tropea VV
Italy

यह अमेरिकी पतों के लिए आदेश से अलग है - दूसरी पंक्ति पर।

SO प्रश्न भी देखें:

टैग ' पोस्टल-कोड ' भी देखें।


संपादित करें : क्षेत्र और शहर का प्रतिवर्ती क्रम - प्रति यूपीयू


5

शायद यह उपयोगी है: https://gist.github.com/259744 एक परियोजना के लिए मैंने दुनिया के सभी देशों के बारे में एक तालिका एकत्र की, जिसमें आईएसओ कोड, शीर्ष स्तर डोमेन, फोन कोड, कार साइन, लंबाई और regex शामिल हैं ज़िप करें। देश के नाम और टिप्पणियां दुर्भाग्य से केवल जर्मन में ...


2

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

आपके पास समस्या यह है कि पूरे देशों में भौगोलिक पदानुक्रम के स्तर में बहुत अधिक भिन्नता है। हेक, कुछ देशों में हर जगह 'सड़क के पते' भी नहीं हैं।

मेरा सुझाव है कि आप इसे बहुत चालाक बनाने की कोशिश न करें।


2

अन्य उत्तरों के भिन्न रूप से, मेरा मानना ​​है कि संरचित एड्रेस डेटाबेस होना संभव है।

टोपी से बाहर, मैं निम्नलिखित संरचना के बारे में सोच सकता हूं:

  • देश
  • क्षेत्र (राज्य / प्रांत)
  • स्थानीयता (शहर / नगर पालिका)
  • उप-इलाके (काउंटी / अन्य उप-विभाजन)
  • सड़क

लेकिन इसे तेजी से कैसे क्वेरी करें?

एक तरह से मुझे हमेशा लगता है कि इसे पूरा किया जा सकता है, ज़िप कोड (या पोस्टल कोड) के लिए पूछना है जो देश से देश में भिन्न होता है, लेकिन देश के भीतर ठोस है।

इस तरह आप दुनिया भर के डाकघरों द्वारा उपलब्ध कराई गई जानकारी के आसपास अपने डेटा को संरचित कर सकते हैं।


2

यूनिवर्सल डेटा मॉडल प्रसिद्धि के लेन सिल्वरस्टन ने एक अलग पदानुक्रम की सिफारिश की है GEOGRAPHIC BOUNDARIESऔर इस पर निर्भर करता है कि आप कितने मुक्त-गठन-नेस या तो सरल STREET ADDRESS LINEएस या प्रति-देश डेरिवेटिव को स्वीकार करने के लिए तैयार हैं ।


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

2

नहीं, बिल्कुल नहीं। यदि आप अमेरिका और जापानी पते की तुलना करते हैं काम करते हैं, तो आप देखेंगे कि यह संभव नहीं है।

अपडेट करें:

दूसरे विचार पर, कुछ भी किया जा सकता है, लेकिन व्यापार बंद है।

एक दृष्टिकोण यह है कि समस्या और पते के साथ समस्या का समाधान करें_टैटर टेबल, उनके बीच 1: m संबंध के साथ, कुछ भी मॉडल किया जा सकता है। Address_attribute तालिका में एक pk, एक नाम, एक मान और एक fk होगा जो उसके पते के जनक pk पर वापस इंगित करता है। यह नाम, मूल्य जोड़े के साथ मानचित्र का उपयोग करना लगभग पसंद है।

हर बार जब आप एक एड्रेस चाहते हैं तो ट्रेड-ऑफ को एक जॉइन करना होता है। आपको यह पता लगाने के लिए भी पता करना होगा कि प्रत्येक बार आप जो व्यवहार कर रहे हैं, उसका पता लगाने के लिए _attributes का नाम लें।

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

अमेज़न या ईबे कैसे करता है? वे अंतरराष्ट्रीय स्तर पर जहाज चलाते हैं। क्या उनके पास विशिष्ट-विशिष्ट UI सुविधाएँ हैं? मैंने केवल US लोकेल का उपयोग किया है।


1
क्या होगा यदि मुझे पते की सबसे अधिक आवश्यकता है?
आर्सेन मकर्त्चयन

क्षमा करें, मैं यहां आपका अनुसरण नहीं कर रहा हूं।
डफिमो

2

नहीं, कोई मानक पता योजना नहीं है। यह आमतौर पर देश-दर-देश बदलता रहता है। यहां तक ​​कि यूनिवर्सल पोस्टल यूनियन ने दुनिया को मानने पर कहा , सभी के लिए एक पता है कि कोई भी नहीं है। इसके लिए सबसे अच्छा समाधान आईएसओ 3166 के रूप में ज्ञात 2/3-अक्षर वाले देश कोड मानकों का उपयोग करना है और देश के मानकों द्वारा बाकी सब का इलाज करना है।

हालांकि, यदि आप वास्तव में अपनी परियोजना के लिए आसानी से सुलभ उपकरणों का उपयोग करने के लिए बेताब हैं, तो आप Google प्लेस एपीआई की कोशिश कर सकते हैं ।


मुझे वास्तव में यह देखना पसंद है कि Google प्लेस एपीआई चीजों को कैसे संभालता है!
एंड्रयू स्टिट्ज़

1

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.