Dünyanın tüm adresleri için ortak sokak adresleri veritabanı tasarımı var mı?

Ben bir programcıyım ve dürüst olmak gerekirse dünyanın sokak adresi yapılarını bilmiyorum, sadece benim ülkemde nasıl bir yapılanma var :) peki sokak adreslerini depolamak için en iyi ve en yaygın veritabanı tasarımı hangisidir? Tek bir kimlik ile tanımlayan dünyanın tüm sokak adreslerini saklamak çok basit, hızlı sorgulama ve dinamik olmalı
Çok teşekkürler

Birçok farklı ülkeden adresleri standart bir alan kümesinde temsil etmek mümkündür. İsimlendirilmiş veya numaralandırılmış binaların üzerinde bulunduğu isimlendirilmiş bir erişim yolu (ana yol) hakkındaki temel fikir, bazen Çin dışında oldukça standarttır. Diğer neredeyse evrensel kavramlar şunlardır: genel olarak bir yerellik olarak adlandırılabilecek yerleşimin (şehir / kasaba / köy) adlandırılması; bölgeyi adlandırmak ve alfasayısal bir posta kodu atamak. Posta kodları olarak da bilinen posta kodlarının yalnızca bazı ülkelerde tamamen sayısal olduğunu unutmayın. Gerçekten jenerik olmak istiyorsanız çok sayıda alana ihtiyacınız olacak.

UPU Evrensel Posta Birliği, birçok ülke için adres verilerini standart bir biçimde sağlar . UPU formatının tüm ülke için tüm adresleri (mevcut alan hassasiyetine kadar) tuttuğunu ve bu nedenle ilişkisel olduğunu unutmayın. Olası tüm adreslerin yalnızca küçük bir kısmının saklanacağı müşteri adreslerini depoluyorsanız, tüm alanları ve satır başına bir adresi içeren tek bir tablo (veya düz biçim) kullanmak daha iyidir.

Adresleri saklamak için makul bir format aşağıdaki gibi olacaktır:

• Adres Satırları 1-4
• mekân
• bölge
• Posta kodu (veya posta kodu)
• ülke

1-4 adres satırları aşağıdakiler gibi bileşenleri barındırabilir:

• bina
• Alt Yapı
• Öncül numarası (ev numarası)
• Premise Aralığı
• işlek cadde
• Alt Ana Yol
• Çift Bağımlı Yerellik
• Alt Çevre

Çoğunlukla yalnızca 3 adres satırı kullanılır, ancak bu genellikle yetersizdir. Elbette, tüm adresleri resmi formatta temsil etmek için daha fazla satıra ihtiyaç duyulabilir, ancak virgül her zaman satır ayırıcı olarak kullanılabilir, yani bilgiler hala yakalanabilir.

Genellikle verilerin analizi yerellik, bölge, posta kodu ve ülkeye göre yapılır ve bu öğeler, kullanıcıların verileri girerken anlaması oldukça kolaydır. Bu nedenle bu elemanlar ayrı alanlar olarak saklanmalıdır. Ancak, kullanıcıları posta kodu veya bölge sağlamaya zorlamayın, bunlar yerel olarak kullanılamaz.

Yerellik, özellikle harita konumu ile posta konumu arasındaki ayrım net olmayabilir. Posta bölgesi, bazen yakındaki büyük bir kasaba olabilen bir posta otoritesi tarafından kabul edilen yerdir. Bununla birlikte, posta kodu, resmi yerellik kullanılmasa bile doğru teslimata izin vermek için genellikle oradaki sorunları veya tutarsızlıkları çözecektir.

Veritabanı Cevaplarına bir göz atın . Özellikle, bu birçok durumu kapsar:

(Tüm değişken uzunluklu karakter veri türü)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Kendinize bu verileri depolamanın ana amacının ne olduğunu sorun. Adresteki kişiye gerçekten posta göndermeyi düşünüyor musunuz? Demografiyi, popülasyonları izlemek? Bazı temel kimlik doğrulama / doğrulama işlemlerinin bir parçası olarak arayanlardan doğru adreslerini isteyebilecek misiniz? Yukarıdakilerin hepsi? Yukarıdakilerin hiçbiri?

Gerçek ihtiyacınıza bağlı olarak, ya a) gerçekten önemli olmadığını ve bir serbest metin yaklaşımına gidebileceğinizi ya da b) tüm ülkeler için yapılandırılmış / belirli alanları ya da c) ülkeye özgü mimariyi belirleyeceksiniz.

Bazen bir sokak adresine ulaşabileceğiniz en yakın adres şehirdir.

Bir zamanlar Hindistan'daki tüm Ortaokulları Google Haritalar'a koyma projem vardı. Google API kullanarak şık bir program yazdım ve oldukça kolay olacağını düşündüm.

Sonra müşteriden verileri aldım. Bazı okul adresleri "Pazarın karşısında, berberin yanında" veya "Eski otobüs durağının yakınında" gibi şeylerdi.

Ne yazık ki Google API bu biçimi desteklemediğinden, görevimi daha da zorlaştırdı.

Uluslararası adresler için, bilgileri alanlara ayrılmışsa biçimlendirmenin bir yolunu bulmak oldukça zordur. Örneğin, bir İtalyan adresi şunları kullanır:

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

Gibi

Via Eroi della Repubblica
89861 Tropea VV
Italy

Bu, ABD adreslerinin sıralamasından oldukça farklı - ikinci satırda.

SO sorularına da bakın:

• Birleşik Krallık veritabanı için kaç adres alanı kullanırsınız?
• Adresleri cadde / şehir / eyalet / posta koduna ayırıyor musunuz?
• Yinelenen sokak ekleriyle nasıl başa çıkarsınız?
• Posta adreslerini bir veritabanında (RDBMS) depolamak için en iyi uygulamalar?

Ayrıca ' posta kodu ' etiketine bakın .

Düzenleme : Bölgenin ve kasabanın sırasını ters çevir - UPU başına

Belki bu yararlıdır: https://gist.github.com/259744 Bir proje için, dünyanın tüm ülkeleri hakkında ISO kodları, üst düzey alan adı, telefon kodu, araba işareti, uzunluk ve normal ifade dahil olmak üzere zip. Ülke isimleri ve yorumları maalesef sadece Almanca olarak ...

Tarlalara ne kadar serbest formda girmeye hazır olduğunuza bağlıdır. Serbest biçimli bir adres alanı elbette her zaman işe yarar, ancak coğrafyayı daraltmada görece çok az yardımcı olacaktır.

Yaşayacağınız sorun, ülkeler arasında coğrafi hiyerarşi seviyesinde çok fazla farklılık olmasıdır. Heck, bazı ülkelerin her yerde 'sokak adresleri' bile yoktur.

Bunu çok zekice yapmaya çalışmamanızı tavsiye ederim.

Buradaki diğer cevaplardan farklı olarak, yapılandırılmış bir adres veritabanına sahip olmanın mümkün olduğuna inanıyorum.

Şapkanın dışında, şu yapıyı düşünebilirim:

• ülke
• Bölge (Eyalet / İl)
• Yer (Şehir / Belediye)
• Alt Mahal (İlçe / bir yerin diğer alt bölümü)
• sokak

Ama yeterince hızlı nasıl sorgulanır?

Her zaman başarılabileceğini düşündüğüm bir yol, ülkeden ülkeye değişen, ancak ülke içinde sağlam olan Posta Kodunu (veya Posta Kodunu) istemektir.

Bu şekilde, verilerinizi dünya genelindeki posta büroları tarafından sağlanan bilgiler çerçevesinde yapılandırabilirsiniz.

Evrensel Veri Modeli şöhretinden Len Silverston, GEOGRAPHIC BOUNDARIESbasit STREET ADDRESS LINEtürevleri veya ülke bazında türevleri ne kadar serbest biçimli kabul etmeye istekli olduğunuza bağlı olarak ayrı bir hiyerarşi önerir .

Kesinlikle değil. ABD ve Japonya adreslerinin çalışma şeklini karşılaştırırsanız, bunun mümkün olmadığını göreceksiniz.

GÜNCELLEME:

İkinci olarak düşündüğümüzde, her şey yapılabilir, ancak bir değiş tokuş var.

Bir yaklaşım, problemi adres ve adres öznitelik tablolarıyla modellemektir, aralarında 1: m'lik bir ilişki vardır, her şey modellenebilir. Address_attribute tablosu bir pk, bir isim, bir değer ve kendi adres ebeveyninin pk'sini gösteren bir fk'ye sahip olacaktır. Neredeyse ad, değer çiftleri olan bir Harita kullanmak gibidir.

Takas, her adres istediğinizde bir JOIN yapmak zorunda kalıyor. Her seferinde neyle karşı karşıya olduğunuzu anlamak için adres_özniteliklerinin adlarını da sorgulamanız gerekir.

Diğer bir yaklaşım, adreslerin dünya genelinde nasıl modellendiği konusunda daha kapsamlı araştırma yapmak olacaktır. Nesne odaklı bir dünyada, adres alanını döşemek için gerektiği kadar çok sayıda, Japonya, Çin için batı Adres sınıfına (sokak1 / sokak2 / şehir / eyalet / posta kodu) ve diğerlerine sahip olabilirsiniz. Daha sonra aralarında 1: 1 ilişki olan bir ana Adres tablonuz ve diğer türler için alt tablolarınız olur.

Amazon veya eBay bunu nasıl yapıyor? Uluslararası olarak gönderiliyorlar. Yerel ayara özgü UI özellikleri var mı? Yalnızca ABD yerel ayarını kullandım.

Hayır, standart bir adresleme şeması yoktur. Genellikle ülkeden ülkeye değişir. Hatta Evrensel Posta Birliği söyledi dünyayı herkes için bir adres Adresleme orada yok olduğunu. Bunun için en iyi çözüm, ISO 3166 olarak bilinen 2/3 harfli ülke kodu standartlarını kullanmak ve diğer her şeyi ülke standartlarına göre ele almaktır .

Ancak, projeniz için kolayca erişilebilir araçları kullanmak konusunda gerçekten çaresizseniz, Google Place API'yi deneyebilirsiniz .

Tasarımınız büyük ölçüde amacınıza bağlı olmalıdır. Bazı insanlar verilerin nasıl yapılandırılacağını yayınladı. Yani birisine sadece e-posta göndermek istiyorsanız, yeterli olacaktır. Bu verileri navigasyon için kullanmak isterseniz işler karmaşıklaşmaya başlar. Araba navigasyonu, trafik bilgisi içermesi için ek yapılar (örn. Tek yönlü yollar) gerektirirken, yaya navigasyonu birçok ek veriye ihtiyaç duyacaktır. İşte küçük bir örnek: benim şehrimde mahallem parkın yakınında. Parkın yanında eski hava alanı (aslında Avrupa'nın en eskilerinden biri) havacılık müzesine dönüştürülmüş. Havacılık müzesinin yanında bir iş parkı var. Müze sokak numarası 39, iş parkı numaraları 39A ile başlıyor. Bu nedenle, 39 ve 39A yakınmış gibi görünebilir - ancak birinden diğerine yürümek yaklaşık bir mil (ve araba ile giderken daha da uzun sürer) sürer.
Bu sadece benim şehrimden alınan küçük bir örnek, bence pek çok istisna bulabilirsin (özellikle her ülkenin kırsal veya vahşi bölgelerinde).