Apakah ada desain database alamat jalan umum untuk semua alamat di dunia?

Saya seorang programmer dan sejujurnya tidak tahu struktur alamat jalan di dunia, hanya bagaimana di negara saya terstruktur :) jadi desain database mana yang terbaik dan umum untuk menyimpan alamat jalan? Ini harus sangat mudah digunakan, cepat untuk query dan dinamis untuk menyimpan semua alamat jalan di dunia yang diidentifikasi hanya dengan satu id
Terima kasih banyak

Dimungkinkan untuk merepresentasikan alamat dari banyak negara yang berbeda dalam kumpulan bidang standar. Ide dasar dari rute akses bernama (jalan raya) di mana bangunan bernama atau bernomor berada cukup standar, kecuali kadang-kadang di Cina. Konsep lain yang hampir universal termasuk: penamaan pemukiman (kota / kota / desa), yang secara umum dapat disebut sebagai lokalitas; menamai wilayah dan menetapkan kode pos alfanumerik. Perhatikan bahwa kode pos, juga dikenal sebagai kode pos, hanya berupa angka di beberapa negara. Anda akan membutuhkan banyak kolom jika Anda benar-benar ingin menjadi generik.

Serikat Pos Universal UPU menyediakan data alamat untuk banyak negara dalam format standar . Perhatikan bahwa format UPU menampung semua alamat (hingga ketepatan bidang yang tersedia) untuk seluruh negara, oleh karena itu bersifat relasional. Jika menyimpan alamat pelanggan, di mana hanya sebagian kecil dari semua kemungkinan alamat akan disimpan, lebih baik menggunakan tabel tunggal (atau format datar) yang berisi semua bidang dan satu alamat per baris.

Format yang wajar untuk menyimpan alamat adalah sebagai berikut:

• Baris Alamat 1-4
• Lokalitas
• Wilayah
• Kode pos (atau kode pos)
• Negara

Baris alamat 1-4 dapat menampung komponen seperti:

• Bangunan
• Sub-Bangunan
• Nomor rumah (nomor rumah)
• Rentang Premis
• Jalan raya
• Sub-Jalan Utama
• Lokalitas Bergantung Ganda
• Sublokalitas

Seringkali hanya 3 baris alamat yang digunakan, tetapi ini seringkali tidak cukup. Tentu saja mungkin untuk meminta lebih banyak baris untuk mewakili semua alamat dalam format resmi, tetapi koma selalu dapat digunakan sebagai pemisah baris, yang berarti informasi masih dapat ditangkap.

Biasanya analisis data akan dilakukan berdasarkan lokalitas, wilayah, kode pos dan negara dan elemen-elemen ini cukup mudah dipahami oleh pengguna saat memasukkan data. Inilah mengapa elemen-elemen ini harus disimpan sebagai bidang terpisah. Namun, jangan paksa pengguna untuk memberikan kode pos atau wilayah, mereka mungkin tidak digunakan secara lokal.

Lokalitas bisa jadi tidak jelas, terutama perbedaan antara lokalitas peta dan lokalitas pos. Lokalitas pos adalah salah satu yang dianggap oleh otoritas pos yang terkadang merupakan kota besar terdekat. Namun, kode pos biasanya akan menyelesaikan masalah atau ketidaksesuaian di sana, untuk memungkinkan pengiriman yang benar bahkan jika pos-lokalitas resmi tidak digunakan.

Lihat Jawaban Database . Secara khusus, ini mencakup banyak kasus:

(Semua tipe data karakter panjang variabel)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Tanyakan pada diri Anda apa tujuan utama menyimpan data ini? Apakah Anda benar-benar ingin mengirim email ke orang di alamat tersebut? Lacak demografi, populasi? Mampu meminta penelepon untuk alamat yang benar sebagai bagian dari beberapa otentikasi / verifikasi dasar? Semua yang di atas? Bukan dari salah satu di atas?

Bergantung pada kebutuhan Anda yang sebenarnya, Anda akan menentukan apakah a) itu tidak terlalu penting, dan Anda dapat menggunakan pendekatan teks bebas, atau b) bidang terstruktur / spesifik untuk semua negara, atau c) arsitektur khusus negara.

Terkadang hal terdekat yang bisa Anda dapatkan ke alamat jalan adalah kota.

Saya pernah memiliki proyek untuk menempatkan semua Sekolah Menengah di India di Google Maps. Saya menulis program yang keren menggunakan Google API dan menurut saya itu akan sangat mudah.

Kemudian saya mendapatkan data dari klien. Beberapa alamat sekolah adalah hal-hal seperti "Di seberang pasar, di samping tukang cukur" atau "Dekat halte bus tua".

Itu membuat tugas saya jauh lebih sulit karena, sayangnya, Google API tidak mendukung format itu.

Untuk alamat internasional, sangat sulit menemukan cara untuk memformat informasi jika dipecah menjadi beberapa bidang. Misalnya, alamat Italia menggunakan:

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

Seperti

Via Eroi della Repubblica
89861 Tropea VV
Italy

Ini agak berbeda dari urutan alamat AS - di baris kedua.

Lihat juga pertanyaan SO:

• Berapa banyak bidang alamat yang akan Anda gunakan untuk database Inggris?
• Apakah Anda membagi alamat menjadi jalan / kota / negara bagian / zip?
• Bagaimana Anda menangani sufiks jalan duplikat?
• Praktik terbaik untuk menyimpan alamat pos dalam database (RDBMS)?

Lihat juga tag ' kode-pos '.

Sunting : Urutan terbalik dari wilayah dan kota - per UPU

Mungkin ini berguna: https://gist.github.com/259744 Untuk sebuah proyek, saya mengumpulkan tabel informasi tentang semua negara di dunia, termasuk kode ISO, domain level teratas, kode telepon, tanda mobil, panjang dan regex dari zip. Nama negara dan komentar sayangnya hanya dalam bahasa Jerman ...

Tergantung pada seberapa bebas Anda siap untuk bekerja di ladang. Satu bidang alamat bentuk bebas jelas akan selalu dilakukan, tetapi relatif sedikit membantu mempersempit geografi.

Masalah yang akan Anda hadapi adalah terlalu banyak variasi dalam tingkat hierarki geografis antar negara. Heck, beberapa negara bahkan tidak memiliki 'alamat jalan' di mana-mana.

Saya sarankan Anda tidak mencoba membuatnya terlalu pintar.

Berbeda dari jawaban lain di sini, saya yakin mungkin memiliki database alamat terstruktur.

Keluar dari topi, saya dapat memikirkan struktur berikut:

• Negara
• Wilayah (Negara Bagian / Provinsi)
• Lokalitas (Kota / Kotamadya)
• Sub-Lokalitas (County / sub-divisi lain dari suatu lokalitas)
• jalan

Tetapi bagaimana cara menanyakannya dengan cukup cepat?

Salah satu cara yang menurut saya selalu dapat dilakukan adalah dengan meminta Kode Pos (atau Kode Pos) yang bervariasi dari satu negara ke negara lain, tetapi solid di dalam negara.

Dengan cara ini Anda dapat menyusun data Anda di sekitar informasi yang disediakan oleh kantor pos di seluruh dunia.

Len Silverston dari Ketenaran Model Data Universal merekomendasikan hierarki terpisah GEOGRAPHIC BOUNDARIESdan bergantung pada seberapa banyak bentuk-bebas Anda bersedia menerima baik STREET ADDRESS LINEturunan sederhana atau per negara.

Tidak, sama sekali tidak. Jika Anda membandingkan cara alamat AS dan Jepang kerja , Anda akan melihat bahwa itu tidak mungkin.

MEMPERBARUI:

Setelah dipikir-pikir, apa pun bisa dilakukan, tetapi ada trade-off.

Salah satu pendekatannya adalah memodelkan masalah dengan tabel address dan address_attribute, dengan hubungan 1: m di antara mereka, apa pun dapat dimodelkan. Tabel address_attribute akan memiliki pk, nama, nilai, dan fk yang menunjuk kembali ke alamat pk induknya. Ini hampir seperti menggunakan Peta dengan nama, pasangan nilai.

Imbalannya adalah harus melakukan GABUNG setiap kali Anda menginginkan alamat. Anda juga harus memeriksa nama address_attributes untuk mengetahui apa yang Anda hadapi setiap saat.

Pendekatan lain adalah melakukan penelitian yang lebih komprehensif tentang bagaimana alamat dimodelkan di seluruh dunia. Dalam dunia yang berorientasi objek Anda mungkin memiliki kelas Alamat barat (jalan1 / jalan2 / kota / negara bagian / zip) dan lainnya untuk Jepang, Cina, sebanyak yang diperlukan untuk menyusun ruang alamat. Kemudian Anda akan memiliki tabel Alamat master dan tabel anak ke tipe lain dengan hubungan 1: 1 di antara keduanya.

Bagaimana Amazon atau eBay melakukannya? Mereka mengirim secara internasional. Apakah mereka memiliki fitur UI khusus lokal? Saya hanya menggunakan lokal AS.

Tidak, tidak ada skema pengalamatan standar. Biasanya bervariasi dari satu negara ke negara. Bahkan Universal Postal Union mengatakan tentang Adressing the world, alamat untuk semua orang yang tidak ada. Solusi terbaik untuk ini adalah dengan menggunakan standar kode negara 2/3-huruf yang dikenal sebagai ISO 3166 dan memperlakukan yang lainnya dengan standar negara.

Namun, jika Anda benar-benar putus asa untuk menggunakan alat yang mudah diakses untuk proyek Anda, Anda dapat mencoba Google Place API .

Desain Anda harus sangat bergantung pada tujuan Anda. Beberapa orang telah memposting cara menyusun data. Jadi jika Anda hanya ingin mengirim s-mail ke seseorang, itu akan dilakukan. Segalanya mulai menjadi rumit jika Anda ingin menggunakan data ini untuk navigasi. Navigasi mobil akan membutuhkan struktur tambahan untuk memuat info lalu lintas (misalnya jalan satu arah), sedangkan navigasi pejalan kaki akan membutuhkan banyak data tambahan. Ini contoh kecilnya: di kota saya, lingkungan saya dekat taman. Di sebelah taman adalah bekas lapangan terbang (sebenarnya, salah satu yang tertua di Eropa) berubah menjadi museum penerbangan. Di sebelah museum penerbangan adalah taman bisnis. Nomor jalan museum adalah 39, sedangkan nomor taman bisnis diawali dengan 39A. Jadi tampaknya 39 dan 39A itu dekat - tapi butuh sekitar satu mil untuk berjalan dari satu ke yang lain (dan bahkan lebih lama jika pergi dengan mobil).
Ini hanyalah contoh kecil yang diambil dari kota saya, saya pikir Anda mungkin dapat menemukan banyak pengecualian (terutama di pedesaan atau bagian yang lebih liar di setiap negara).