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.