Praktik terbaik untuk menyimpan alamat pos dalam database (RDBMS)?

Apakah ada referensi yang baik untuk praktik terbaik untuk menyimpan alamat pos di RDBMS? Tampaknya ada banyak pengorbanan yang dapat dilakukan dan banyak pro dan kontra untuk dievaluasi - tentunya ini telah dilakukan berkali-kali? Mungkin seseorang setidaknya telah menulis beberapa pelajaran yang dipelajari di suatu tempat?

Contoh pengorbanan yang saya bicarakan adalah menyimpan kode pos sebagai bilangan bulat vs bidang karakter, haruskah nomor rumah disimpan sebagai bidang terpisah atau bagian dari baris alamat 1, apakah nomor suite / apartemen / dll harus dinormalisasi atau hanya disimpan sebagai potongan teks di baris alamat 2, bagaimana Anda menangani zip +4 (bidang terpisah atau satu bidang besar, integer vs teks)? dll.

Saya terutama prihatin dengan alamat AS pada saat ini, tetapi saya membayangkan ada beberapa praktik terbaik dalam hal mempersiapkan diri Anda untuk kemungkinan menjadi global juga (misalnya, menamai bidang dengan tepat seperti wilayah, bukan negara bagian atau kode pos, bukan kode pos, dll.

Untuk penggunaan yang lebih internasional, satu skema yang perlu dipertimbangkan adalah yang digunakan oleh Bidang Alamat Drupal . Ini didasarkan pada standar xNAL , dan tampaknya mencakup sebagian besar kasus internasional. Sedikit menggali ke dalam modul itu akan mengungkapkan beberapa mutiara bagus untuk menafsirkan dan memvalidasi alamat secara internasional. Ini juga memiliki satu set area administratif yang bagus (provinsi, negara bagian, oblast, dll) dengan kode ISO.

Berikut inti dari skema, disalin dari halaman modul:

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)

Pelajaran yang saya pelajari:

• Jangan simpan apapun secara numerik.
• Simpan negara dan wilayah administratif sebagai kode ISO jika memungkinkan.
• Jika Anda tidak tahu, lalai dalam meminta ladang. Beberapa negara mungkin tidak menggunakan bidang yang Anda anggap remeh, bahkan hal-hal dasar seperti locality& thoroughfare.

Sebagai pengguna 'internasional', tidak ada yang lebih membuat frustrasi daripada berurusan dengan situs web yang hanya berorientasi pada alamat format AS. Ini sedikit kasar pada awalnya, tetapi menjadi masalah serius ketika validasinya juga terlalu berlebihan.

Jika Anda ingin menjadi global, satu-satunya saran yang saya miliki adalah menjaga agar segala sesuatunya tetap bebas. Negara yang berbeda memiliki konvensi yang berbeda - di beberapa negara, nomor rumah muncul sebelum nama jalan, di beberapa negara lainnya setelah. Beberapa memiliki negara bagian, beberapa wilayah, beberapa kabupaten, beberapa kombinasi dari itu. Di sini, di Inggris, kode posnya bukanlah kode pos, ini adalah kode pos yang berisi huruf dan angka.

Saya hanya menyarankan ~ 10 baris string dengan panjang variabel, bersama dengan bidang terpisah untuk kode pos (dan hati-hati bagaimana Anda menggambarkannya untuk mengatasi kepekaan nasional). Biarkan pengguna / pelanggan memutuskan bagaimana menulis alamat mereka.

Jika Anda memerlukan informasi lengkap tentang bagaimana negara lain menggunakan alamat pos, berikut adalah tautan referensi yang sangat bagus (Universitas Columbia):

Panduan Kompulsif Frank untuk Alamat Pos
Pengalamatan yang Efektif untuk Surat Internasional

Anda pasti harus mempertimbangkan untuk menyimpan nomor rumah sebagai bidang karakter daripada angka, karena kasus khusus seperti "setengah-angka", atau alamat saya saat ini, yang seperti "129A" ​​- tetapi A tidak dianggap sebagai apartemen nomor untuk layanan pengiriman.

Saya telah melakukan ini (model struktur alamat yang ketat dalam database), dan saya tidak akan pernah melakukannya lagi. Anda tidak dapat membayangkan betapa gilanya pengecualian yang harus Anda perhitungkan sebagai suatu peraturan.

Saya samar-samar mengingat beberapa masalah dengan kode pos Norwegia (menurut saya), yang semuanya 4 posisi, kecuali Oslo, yang memiliki 18 atau lebih.

Saya sangat yakin bahwa sejak kami mulai menggunakan kode pos yang benar secara geografis untuk semua alamat nasional kami, cukup banyak orang mulai mengeluh bahwa surat mereka datang terlambat. Ternyata orang-orang itu tinggal di dekat perbatasan antar wilayah pos, dan meskipun sebenarnya ada yang tinggal di wilayah pos, katakanlah 1600, pada kenyataannya suratnya harus ditujukan ke wilayah pos 1610, karena kenyataannya itu adalah wilayah pos tetangga. yang benar-benar melayaninya, jadi mengirim surat ke area pos yang benar akan membutuhkan waktu beberapa hari lagi untuk sampai, karena intervensi yang tidak diinginkan yang diperlukan di kantor pos yang benar untuk meneruskannya ke area pos yang salah ...

(Kami akhirnya mendaftarkan orang-orang dengan alamat di luar negeri di negara dengan kode ISO 'ZZ'.)

Anda tentunya harus berkonsultasi dengan " Apakah ini cara yang baik untuk memodelkan informasi alamat dalam database relasional ", tetapi pertanyaan Anda bukanlah duplikat langsung dari itu.

Pasti ada banyak jawaban yang sudah ada sebelumnya (lihat contoh model data di DatabaseAnswers , misalnya). Banyak dari jawaban yang sudah ada sebelumnya rusak dalam beberapa keadaan (tidak memilih DB Answers sama sekali).

Salah satu masalah utama yang perlu dipertimbangkan adalah cakupan alamat. Jika database Anda harus berurusan dengan alamat internasional, Anda harus lebih fleksibel daripada jika Anda hanya berurusan dengan alamat di satu negara.

Dalam pandangan saya, seringkali (yang tidak berarti selalu ) masuk akal untuk merekam 'gambar label alamat' dari alamat dan menganalisis konten secara terpisah. Ini memungkinkan Anda untuk mengatasi perbedaan antara penempatan kode pos, misalnya, di antara negara yang berbeda. Tentu, Anda dapat menulis penganalisis dan pemformat yang menangani keeksentrikan negara yang berbeda (misalnya, alamat AS memiliki 2 atau 3 baris; sebaliknya, alamat Inggris dapat memiliki lebih banyak; satu alamat yang saya tulis secara berkala memiliki 9 baris). Tetapi akan lebih mudah untuk meminta manusia melakukan analisis dan pemformatan dan membiarkan DBMS hanya menyimpan data.

Kecuali jika Anda akan mengerjakan matematika tentang nomor jalan atau kode pos / pos, Anda hanya mengundang rasa sakit di masa depan dengan menyimpannya sebagai angka.

Anda mungkin menghemat beberapa byte di sana-sini, dan mungkin mendapatkan indeks yang lebih cepat, tetapi apa yang Anda lakukan ketika pos AS, atau negara lain mana pun yang Anda hadapi, memutuskan untuk memasukkan alfa ke dalam kode?

Biaya ruang disk akan jauh lebih murah daripada biaya memperbaikinya nanti ... y2k siapa?

Menambahkan apa @ Jonathan Leffler dan @ Paul Fisher mengatakan

Jika Anda pernah berharap memiliki alamat pos untuk Kanada atau Meksiko ditambahkan ke kebutuhan Anda, menyimpan postal-codesebagai string adalah suatu keharusan. Kanada memiliki kode pos alfa-numerik dan saya tidak ingat seperti apa rupa Meksiko.

Saya telah menemukan bahwa mendaftar semua bidang yang mungkin dari unit diskrit terkecil hingga terbesar adalah cara termudah. Pengguna akan mengisi bidang yang mereka inginkan. Tabel alamat saya terlihat seperti ini:

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

Di mana "trade off" dalam menyimpan ZIP sebagai NOMOR atau VARCHAR? Itu hanya sebuah pilihan - ini bukan trade off kecuali ada manfaat bagi keduanya dan Anda harus melepaskan beberapa manfaat untuk mendapatkan yang lain.

Kecuali jumlah ritsleting memiliki arti sama sekali, Zips sebagai angka tidak berguna.

Ini mungkin berlebihan, tetapi jika Anda memerlukan solusi yang dapat digunakan dengan banyak negara dan Anda perlu memproses bagian alamat secara terprogram:

Anda dapat meminta penanganan alamat khusus negara menggunakan dua tabel: Satu tabel umum dengan 10 kolom VARCHAR2, 10 kolom Angka, tabel lain yang memetakan bidang ini ke petunjuk dan memiliki kolom negara yang mengikat struktur alamat ke suatu negara.

Jika Anda harus memverifikasi alamat atau menggunakannya untuk memproses pembayaran kartu kredit, Anda setidaknya memerlukan sedikit struktur. Blok teks bentuk bebas tidak berfungsi dengan baik untuk itu.

Kode pos adalah bidang opsional umum untuk memvalidasi transaksi kartu pembayaran tanpa menggunakan alamat lengkap. Jadi, miliki bidang terpisah dan berukuran besar untuk itu (setidaknya 10 karakter).

Terinspirasi oleh Jawaban Database

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Saya hanya akan menempatkan semua bidang bersama-sama dalam bidang NVARCHAR (1000) besar, dengan elemen textarea bagi pengguna untuk memasukkan nilai (kecuali Anda ingin melakukan analisis pada misalnya kode pos). Semua masukan baris alamat 1, baris alamat 2, dll. Sangat mengganggu jika Anda memiliki alamat yang tidak sesuai dengan format itu (dan, Anda tahu, ada negara lain selain AS).