Masalah apa yang dipecahkan dengan memisahkan alamat jalan menjadi kolom-kolom tersendiri?

Kami memiliki tim yang merancang tabel dan hubungan untuk pengembang perangkat lunak. Di organisasi kami, mereka cukup ketat dalam menegakkan normalisasi 3NF - yang sejujurnya, saya setuju dengan ukuran organisasi kami dan bagaimana kebutuhan atau klien kami berubah seiring waktu. Hanya ada satu bidang yang saya tidak jelas tentang alasan di balik keputusan desain mereka: alamat.

Meskipun sebagian besar berfokus pada alamat di Amerika Serikat, saya pikir ini bisa berlaku untuk negara mana pun yang melakukan ini. Setiap bagian dari alamat mendapatkan kolomnya sendiri di tabel alamat. Misalnya, ambil alamat US gnarly ini:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

Itu akan terpecah dalam database seperti ini:

• Nomor jalan: 485
• Fraksi jalan: 1/2
• Jalan pra-arah: N (Utara)
• Nama jalan: Smith
• Jenis jalan: ST (Jalan)
• Jalan post-directional: SW (Southwest)
• Kota: Chicago
• Negara: IL (Illinois)
• Kode pos: 11111
• Kode Pos: 2222
• Negara (diasumsikan sebagai AS)
• Perhatian: Jane Doe
• PO Box: NULL
• Jenis tempat tinggal: APT (Apartemen)
• Jumlah tempat tinggal: 300B

Dan akan ada beberapa kolom lain yang terkait dengan rute pedesaan dan rute kontrak. Selain itu, aplikasi spesifik kami kemungkinan akan memiliki beberapa alamat internasional di dalamnya. Pemodel data mengatakan mereka akan menambahkan kolom khusus untuk alamat internasional, yang akan menjadi baris normal 1, baris 2 bidang.

Pada awalnya saya pikir ini WAY overboard. Meneliti online berulang kali mengacu pada menggunakan baris alamat 1, 2, 3 dan mungkin 4, lalu memisahkan kota, wilayah, dan kode pos. Kami memiliki satu kasus penggunaan untuk aplikasi baru kami di mana rincian ini bermanfaat. Kami harus memvalidasi bahwa pengguna tidak membuat bisnis duplikat, dan memeriksa alamat adalah salah satu validasinya. Kita bisa membuatnya bekerja dengan address line 1 dan 2, tetapi itu akan lebih sulit.

Adapun aplikasi spesifik kami, kami perlu menyimpan berbagai jenis alamat untuk bisnis dan orang (fisik, surat, pengiriman, dll). Kita mungkin perlu membuat surat formulir yang dapat dicetak, tetapi persyaratan itu belum dibahas sejauh ini.

Beberapa hal lain yang perlu didukung aplikasi dalam organisasi kami:

• Audit (dengan tabel riwayat lengkap)
• Mencetak label surat
• Menghasilkan formulir yang dicetak
• Pelaporan (untuk pemerintah pusat dan daerah)

Meskipun aplikasi kita mungkin tidak melakukan semua hal yang dilakukan oleh setiap aplikasi lain, membagi alamat menjadi beberapa komponen adalah standar perusahaan tempat saya bekerja. Terlepas dari apakah aplikasi kami akan mendapat manfaat dari itu, kami terpaksa melakukan ini.

Pertanyaan terkait StackOverflow semi terkait: Di mana Address Parser baik yang ditutup, tetapi menggambarkan betapa sulitnya menguraikan alamat.

Agar saya lebih memahami keputusan desain mereka, dan untuk menjual klien kami pada ide ...

Masalah apa yang dipecahkan dengan memisahkan alamat jalan menjadi kolom-kolom tersendiri?

Poin bonus untuk siapa saja yang telah menerapkan sistem seperti ini, karena mereka mengalami masalah.

Masalah yang bisa diselesaikan dengan pemecahan termasuk

Validasi Setiap bagian dari nama dapat dibandingkan dengan daftar utama. Yang tidak cocok bisa ditolak. Kode pos / kode pos adalah contoh nyata. Ini dikeluarkan dan dikelola oleh otoritas independen. Satu-satunya yang valid adalah yang dikeluarkan oleh otoritas itu.

Penyortiran dan Pemilihan Saya telah melihat kasus-kasus di mana biaya pos berkurang jika surat diserahkan ke layanan pengiriman yang sudah diatur sampai batas tertentu. Memiliki kolom yang sesuai menghasilkan nilai bisnis yang nyata.

Analisis Dapat bermanfaat untuk mengetahui ke mana pesanan Anda akan, dengan cara yang hierarkis secara geografis. Ini dapat mendorong inisiatif penjualan, pengembangan produk atau pembayaran komisi dll.

Duplikasi Kode Dengan memiliki semua aplikasi dalam suatu organisasi mengadopsi model data yang sama (yaitu dari konsumen yang paling kompleks), basis kode tunggal dapat diadopsi di seluruh perusahaan dan dipelihara secara konsisten. Pemisahan rambut tanpa akhir yang diduplikasi dapat dihindari, atau setidaknya didelegasikan ke propellerhead. Alamat yang dipegang oleh berbagai bagian organisasi dapat diperbarui secara konsisten. Layanan dan kepuasan pelanggan dapat ditingkatkan. Upaya pengembangan dapat berkonsentrasi pada bagian unik dan bernilai tinggi dari suatu sistem.

Masalah Hukum Hukum dan pajak berbeda-beda berdasarkan yurisdiksi. Dengan mengambil nilai alamat terperinci secara terpisah, lebih mudah untuk mereferensikan data transaksional dengan persyaratan kepatuhan.

Duplikasi Mudah untuk menipu alamat yang disimpan sebagai teks dengan memindahkan satu elemen ke baris berikutnya atau menyesuaikan kembali beberapa bagian. Alamat yang diurai sepenuhnya lebih mudah dibandingkan. Ini mungkin masalah kualitas data yang sederhana, atau mungkin memiliki kepatuhan atau implikasi kredit jika, katakanlah, beberapa perusahaan shell membuat pesanan besar ke alamat pengiriman yang sama, atau kartu kredit digunakan untuk mengirim ke banyak lokasi yang tersebar dalam waktu singkat.

Memformat Bagian yang dipegang secara terpisah dapat dikombinasikan dalam mode apa pun yang sesuai dengan kebutuhan saat ini. Jika, misalnya, label cetak tipis panjang menjadi murah, Anda dapat memformat ulang untuk menggunakannya.

Tentu saja tidak satupun dari ini berlaku untuk aplikasi spesifik apa pun. Data jenis ini jauh lebih mudah diurai dan divalidasi pada sumbernya, ketika dikumpulkan, daripada yang pernah ada dalam analisis pasca. Jadi, bahkan jika YAGNI mungkin lebih baik untuk menempatkan upaya ekstra di depan untuk biaya kecil dan potensi penghematan besar di masa depan.

Akhirnya, saya tidak akan mengabaikan faktor manusia. Model data diproduksi oleh pemodel data. Itu yang mereka lakukan. Itu profesi mereka. Mereka tidak akan memberitahu Anda untuk membuangnya dalam Gumpalan, bukan?

Saya menghabiskan 7 tahun mengembangkan perangkat lunak untuk perusahaan penerbitan dan salah satu masalah tersulit yang pernah kami tangani adalah mengurai alamat jalan dalam daftar berlangganan. Sangat berguna untuk membagi alamat menjadi bidang-bidang yang berbeda, tetapi Anda tidak pernah bisa, pernah merancang untuk setiap penyimpangan patologis yang mungkin dari format alamat dan komponen yang dapat dirancang oleh otak manusia.

Setiap tempat dapat memiliki kebiasaannya, dan itu hanya di AS. Lempar ke negara lain dan segala sesuatunya menjadi tidak terkelola dengan sangat cepat untuk setiap pendekatan yang ingin mengurai setiap alamat. Hanya dua contoh:

Di Spanyol, nomor jalan selalu muncul setelah nama jalan dan koma, dan banyak alamat berisi nomor urut lantai, seperti 1 ° atau 3ª, bersama dengan singkatan "kiri" ("Izda" yang berarti pintu kiri setelah Anda naik tangga), "benar" ("Dcha") atau kemungkinan lain. Sekarang gandakan quirkiness itu dengan jumlah negara dan wilayah yang berbeda dengan adat istiadat yang berbeda untuk alamat ... (Jepang? Pedesaan Inggris? Korea? China?)

Di Portland, OR, ada sumbu NS dan EW yang membagi kota menjadi kuadran NW, NE, SW, dan SE (serta kuadran "N", tetapi saya ngelantur). Jalan-jalan NS diberi nomor secara berangsur-angsur dari Timur dan Barat dari poros ini, dan alamat pada jalan-jalan EW ditentukan oleh nomor jalan NS sebagai "seratus blok" dari nomor (yaitu sebuah rumah di jalan EW antara jalan 11 dan 12 akan memiliki nomor seperti 1123). Barang standar cantik untuk alamat AS.

Setiap begitu sering Anda mengalami alamat Portland seperti 0205 SW Nebraska St . Angka nol di depan? WTF? Ini integerkolom saya untuk "nomor" rumah.

Ketika kisi diatur, sumbu NS ditentukan oleh sungai Willamette. Segala sesuatu di sebelah timur sungai adalah NE atau SE, dan sebelah barat sungai NW atau SW. Ketika kota tumbuh ke selatan, mereka berhadapan dengan fakta yang tidak nyaman bahwa sungai berliku ke Timur, sehingga memproyeksikan poros Selatan Anda memiliki area bermasalah yang berada di sisi "Barat" sungai tetapi Timur sumbu. Solusinya adalah dengan menambahkan nol di depan, pada dasarnya tanda minus , dengan angka-angka bertambah ke arah Timur dari garis sumbu.

Jika saya jadi Anda, saya akan menyerah harapan merancang sistem utama. Anda tidak dapat mencakup semua kemungkinan, dan yang baru akan dibuat ketika manusia mendorong ke tanah yang sebelumnya tidak berkembang.

Untuk alamat AS, lihat apa yang telah dilakukan USPS dalam standardisasi alamat, dan ingat untuk membuat house_numberkolom a varchar. Meskipun Anda berada di itu mencari tahu bagaimana Anda akan mengurai 1634 EN Fort Lane Ave .

Untuk seluruh dunia, saya mungkin akan mencoba untuk mengabstraksi bidang tambahan untuk mencakup 80-90% dari apa yang mungkin muncul, dan menyediakan satu set bidang yang tidak diinterpretasikan yang dapat menangani segala sesuatu yang lain bila diperlukan. Yaitu jika parser Anda gagal menangani alamat, simpan alamat itu tidak diuraikan dan ditandai seperti itu. Jika Anda berhasil mem-parsing alamat, pastikan Anda mengingat urutan di mana Anda menemukan berbagai bidang sehingga Anda dapat menyusunnya kembali menjadi sesuatu yang dapat dikirimkan.

Saya akan mengatakan bahwa bidang yang paling penting adalah kode pos, tetapi bahkan itu tidak diberikan di banyak tempat.

Semoga berhasil. Ini bisa menjadi usaha yang menyenangkan dan sangat membuat frustasi tetapi kunci untuk kewarasan adalah mengetahui kapan harus berhenti mencoba dan hanya menyimpan input yang tidak diuraikan, atau sebagian diuraikan dengan input asli sebagai cadangan.

Seperti semua pertanyaan desain, ada "itu tergantung" sangat berkualitas. Itu tergantung pada cerita data Anda - bagaimana data dikumpulkan, bagaimana data itu digunakan, bagaimana data itu diperbarui, dll. Semua komentar saya harus diambil sebagai poin diskusi, bukan jawaban cara.

Kedengarannya seperti * Anda bisa mendapat manfaat lebih dari menggunakan layanan validasi alamat daripada mencoba membangunnya sendiri. Walaupun biayanya mahal, banyak layanan semacam itu datang dengan diskon pengiriman yang signifikan.

Tentu saja, ada kompromi di sini, untuk cerita data tertentu. Anda bisa bertahan potongan alamat diurai dan membuat kolom dihitung (set kolom, kemungkinan) untuk alamat gabungan. Ini adalah jawaban implementasi, dengan semua peringatan normal tersirat.

Saya telah menerapkan desain alamat yang diuraikan. Kami benar-benar membutuhkan ini untuk kualitas data dan kebutuhan pemrosesan data. Tapi itu adalah bisnis yang memiliki alamat fisik, alamat pos, alamat virtual, dll.

Masalah lain yang dapat muncul adalah bahwa layanan pos yang berbeda memerlukan informasi yang sama untuk disajikan dalam berbagai format / pesanan / dll. Jadi memiliki bagian-bagian yang dimodelkan mendukung penyajian info yang sama dalam berbagai format dan tata letak.

Akhirnya, Anda tidak perlu memiliki operasi bisnis internasional untuk harus mendukung data internasional. Bahkan bisnis yang berbasis di AS perlu mendukung alamat internasional. Merupakan kesalahan data yang sangat besar untuk menganggap Anda tidak akan pernah memilikinya. Pelanggan pindah, vendor mengubah HQ, info kontak vendor dapat menjadi internasional bahkan jika mereka memiliki US HQ. Bahkan jika sistem Anda saat ini melakukan kesalahan itu, Anda tidak ingin meneruskan yang ini.

Saya sangat merekomendasikan tulisan dan blog oleh Graham Rhind. Dia ahli dalam bidang data tentang alamat dari semua jenis dan pertukaran yang terkait dengan mereka.

_{* Yang saya katakan di sini adalah generalisasi bruto. Ada begitu banyak pertanyaan yang harus saya bantu untuk menemukan solusi desain yang mungkin membutuhkan beberapa jam mengobrol. Mungkin beberapa gambar dan beberapa profil data juga. Dan kemudian banyak cerita data yang sangat aneh tentang alamat.}

Benar-benar mengesampingkan tantangan besar untuk memilah dengan benar omong kosong tak terduga yang disediakan orang, manfaat dari mem-parsing adalah memberi Anda dimensi untuk pengelompokan dan penyortiran. Kode pos, misalnya. Namun, tidak ada hasil dari memilah dimensi tertentu hingga Anda perlu mengelompokkan atau mengurutkan dimensi tersebut.

Apa itu alamat? Anda dapat membuat kasus yang baik sebagai pengidentifikasi lokasi, tetapi Anda dapat membuat kasus yang sama bagusnya dengan instruksi pengiriman - "Jalan dari pabrik semen". Di Australia, orang mengira kode pos adalah pengidentifikasi lokasi, tetapi bukan, itu adalah kode perutean - instruksi pengiriman. 4702 adalah Rockhampton Mail Centre, sebuah simpul distribusi utama yang melayani wilayah yang membentang dari laut ke Emerald, sebuah kota pertambangan 300km ke daratan.

Jika Anda ingin mengidentifikasi lokasi maka Bing dan Google dapat melakukan geocode langsung dari string yang tidak diparsing ke dalam koordinat GPS, yang dapat disimpan dalam sebuah tabel kecil, sederhana bersama dengan string yang tidak diarsir. Mereka menggunakan satu-satunya pendekatan umum dengan peluang hasil yang secara konsisten baik: pencocokan parsial tertimbang peringkat dengan database kolosal hasil divalidasi.

Jika Anda menginginkan instruksi pengiriman, Anda masih disarankan untuk menyimpan string yang tidak di-parsing karena dapat berisi apa saja .

Perhatikan bahwa dalam kedua kasus saya merekomendasikan menjaga string yang tidak diuraikan. Itu karena

• itu berguna dalam dirinya sendiri
• suatu hari Anda akan mengetahui cara menguraikannya
• beberapa hari setelah itu, Anda akan mengetahui cara menguraikannya dengan benar
• ini tidak pernah berakhir

Bisa dibilang alamat selalu merupakan instruksi pengiriman, yang mengandung setidaknya satu pengidentifikasi lokasi. Sebuah surat yang ditujukan ke "123 Main st, Emerald 4702" mengkodekan tiga lokasi: RMC di bagian utara Rockhampton, Emerald, dan alamat jalan. Kantor pos Rockhampton hanya akan mengirimkannya ke RMC. RMC akan mengirimkannya ke kantor pos Emerald, dan kantor pos Emerald mudah-mudahan tahu di mana menemukan 123 jalan utama.

Saya telah menerapkan sistem seperti ini sebelumnya, meskipun di Belanda. Masalahnya, informasi seperti ini dapat berubah lebih dari yang Anda pikirkan. Jalan-jalan diubah namanya, kota-kota digabungkan dan seterusnya. Sangat menyenangkan untuk dapat memperbarui informasi semacam itu tanpa menguraikan alamat sebagai string tunggal.

Memisahkan kode pos / kode pos, nama bangunan, nama jalan bisa masuk akal. Tetapi kemudian ketika Anda mulai menambahkan "kota", "area" dll, hal itu dipertanyakan, dibandingkan dengan hanya line1, line2 dll. Masalahnya adalah bahkan saya dan istri saya tidak bisa menyetujui nama kota tempat kami tinggal! Apakah nama "desa" diletakkan di lapangan kota, atau apakah masuk dalam baris di bawah nama jalan, dengan kota lokal diletakkan di ladang kota? (Beberapa orang tersinggung jika Anda menyebut di mana mereka tinggal di desa daripada di kota, orang lain yang tinggal di lokasi yang sama tersinggung jika Anda menyebutnya kota daripada desa!)

Karena itu mencoba melakukan hal-hal mewah tidak lebih baik daripada sistem verifikasi alamat yang Anda gunakan. Tapi itu semakin buruk. Di Inggris, SEMUA alamat harus memiliki kode pos, tetapi kode pos tidak dialokasikan sampai beberapa saat setelah rumah dibangun …… Jadi sistem harus mengizinkan setiap aturan tentang alamat dilanggar!

Selain masalah yang telah disebutkan dalam jawaban lain, dalam beberapa bahasa - bahasa Jerman khususnya - nama jalan cenderung majemuk. Sebagai contoh, di banyak kota di Jerman terdapat "Bahnhofstrasse", jalan yang menuju stasiun kereta api ("Bahnhof" yang berarti stasiun kereta api, "Strasse" yang berarti jalan). Tentu saja Anda dapat memisahkan kedua komponen ini, tetapi sekarang jika Anda ingin menyatukannya kembali (secara terprogram) Anda sedang mempertanyakan kemunduran.

Atau, dalam "romansa" atau bahasa Latin, Anda sering memiliki nama jalan dari bentuk "Rue de la Pais" atau "Boulevard des Champs-Élysées". Sekarang Anda memiliki preposisi ("de") dan artikel yang pasti ("le" atau "la") dalam campuran - dan mereka dapat digabungkan. Apakah mereka mewakili bagian dari tipe jalan atau nama jalan? (Anda mungkin perlu menyimpannya di suatu tempat, jika tidak Anda akan memasuki kemunduran lagi.)

Saya pernah memodelkan sesuatu seperti ini. Tapi itu adalah aplikasi yang sangat kecil, untuk kantor pemeliharaan properti perumahan dari universitas menengah (di AS). Saya membuat alamatnya sangat terperinci karena alasan berikut:

• Ada jalan-jalan di daerah dengan nama yang sama tetapi "jenis" jalan yang berbeda (misalnya "Woods Avenue" vs "Woods Court").
• Para pengguna ingin dapat mengoptimalkan pekerjaan pemeliharaan misalnya jika ada dua atau lebih permintaan layanan pada blok yang sama yang dapat ditangani pada saat yang sama.
• Para pengguna ingin dapat mengkorelasikan masalah antara unit yang berbeda (apartemen) di gedung yang sama - misalnya jika lebih dari satu apartemen melaporkan suhu dingin atau kekurangan air panas.

... dan alasan lain yang tidak lagi saya ingat. (Ini terjadi pada akhir 1980-an.)

Dan lagi, ini hanya masuk akal karena ada sejumlah kecil alamat (dan aturan pemformatan alamat) yang harus dihadapi. Saya tidak percaya pendekatan ini akan berkembang, bahkan jika terbatas pada alamat AS, untuk alasan yang sudah diberikan dalam jawaban lain.