Saya perlu menyimpan kode pos di database. Seberapa besar seharusnya kolom tersebut?

103

Saya berharap kolom tersebut menjadi VARCHAR2, di Oracle Database saya.

Zip AS adalah 9.

Kanada berusia 7 tahun.

Saya pikir 32 karakter akan menjadi batas atas yang masuk akal

Apa yang saya lewatkan?

[EDIT] TIL: 12 adalah jawaban yang masuk akal untuk pertanyaan Terima kasih kepada semua orang yang berkontribusi.

— EvilTeach
sumber

Tautan yang berguna, namun akurasinya mungkin sedikit keluar. Misalnya, daftar kode pos Australia terdiri dari 7 karakter, padahal sebenarnya mereka adalah 4. Ref: en.wikipedia.org/wiki/Postcodes_in_Australia dan daftar kode pos tersedia di www1.auspost.com.au/postcodes .

— rossp

re: komentar saya sebelumnya - itu tidak berarti daftar ini tidak berguna sebagai panduan. Dengan asumsi daftar keliru di sisi kode pos yang lebih panjang, panjang terpanjang adalah 9 karakter sehingga 16 karakter atau sekitar itu akan memberi Anda banyak ruang untuk bernafas.

— rossp

Juga daftar negara agak pendek. Saya yakin ada lebih banyak negara di planet ini daripada yang terdaftar ...

— Robert Koritnik

2

Menurut en.wikipedia.org/wiki/List_of_postal_codes , yang terpanjang adalah 12 karakter, jika Anda menyimpan '-', selain itu 11

— Neil McGuigan

@CMS: Anda mungkin ingin memperbarui tautan ke laman wikipedia ini , sepertinya lebih detail.

— Vajk Hermecz

51

Melihat-lihat halaman Kode Pos Wikipedia , 32 karakter sudah lebih dari cukup. Saya akan mengatakan bahkan 16 karakter itu baik.

— strager
sumber

8

Tautan bagus. Bahkan mengizinkan tanda baca dalam US ZIP + 4, 10 karakter sudah cukup untuk negara mana pun sejauh yang saya tahu.

— Jonathan Leffler

Berdasarkan tautan ini, dari laman yang ditautkan di atas, saya akan memilih 18 untuk mengakomodasi negara-negara seperti Chili: en.wikipedia.org/wiki/List_of_postal_codes

— mopo922

5

Chili terdiri dari 7 karakter. Halaman web yang Anda referensikan hanya menunjukkan varian tanda baca.

— EvilTeach

21

Seperti yang telah dikemukakan oleh @ neil-mcguigan, wikipedia memiliki halaman yang layak tentang topik tersebut. Berdasarkan 12 karakter itu harus melakukannya: http://en.wikipedia.org/wiki/List_of_postal_codes

Artikel wikipedia mencantumkan ~ 254 negara, yang cukup bagus mengenai UPU (Universal Postal Union) memiliki 192 negara anggota.

— Vajk Hermecz
sumber

2

Perhatikan bahwa Montserrat hanya 8 karakter, 1110-1350 menunjukkan rentang. discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Mungkin Wikipedia perlu diedit, karena kode pos yang mirip untuk Malta memiliki kode umum seperti "AAA NNNN". Saya tidak akan keberatan untuk memiliki bahkan 15 karakter karena itu hanya bisa menjadi masalah yang lebih sedikit nanti jika kita harus menyesuaikan panjang kolom, juga dengan penggunaan tipe data yang benar, itu tidak boleh mengambil semua 15 karakter (mungkin varchar atau nvarchar atau seperti?) .

— Manohar Reddy Poreddy

12

Mengapa Anda menyatakan ukuran bidang lebih besar dari data sebenarnya yang ingin Anda simpan di dalamnya?

Jika versi awal aplikasi Anda akan mendukung alamat AS dan Kanada (yang saya simpulkan dari fakta bahwa Anda menyebutkan ukuran tersebut dalam pertanyaan Anda), saya akan mendeklarasikan bidang tersebut sebagai VARCHAR2 (9) (atau VARCHAR2 ( 10) jika Anda ingin menyimpan tanda hubung di kolom ZIP + 4). Bahkan melihat kiriman yang dibuat orang lain pada kode pos di berbagai negara, VARCHAR2 (9) atau VARCHAR2 (10) akan cukup untuk sebagian besar, jika tidak semua negara lain.

Selanjutnya, Anda selalu dapat MENGUBAH kolom untuk menambah panjang jika diperlukan. Tetapi secara umum sulit untuk mencegah seseorang, entah di mana, memutuskan untuk menjadi "kreatif" dan memasukkan 50 karakter ke dalam bidang VARCHAR2 (50) karena satu dan lain alasan (yaitu karena mereka menginginkan baris lain pada label pengiriman). Anda juga harus berurusan dengan pengujian kasus batas (akankah setiap aplikasi yang menampilkan ZIP menangani 50 karakter?). Dan dengan fakta bahwa saat klien mengambil data dari database, mereka umumnya mengalokasikan memori berdasarkan ukuran maksimum data yang akan diambil, bukan panjang sebenarnya dari baris tertentu. Mungkin bukan masalah besar dalam kasus khusus ini, tetapi 40 byte per baris bisa menjadi potongan RAM yang layak untuk beberapa situasi.

Selain itu, Anda juga dapat mempertimbangkan untuk menyimpan (setidaknya untuk alamat AS) kode pos dan ekstensi +4 secara terpisah. Secara umum berguna untuk dapat menghasilkan laporan menurut wilayah geografis, dan Anda mungkin sering ingin memasukkan semuanya ke dalam kode ZIP daripada memecahnya dengan ekstensi +4. Pada tahap ini, sebaiknya Anda tidak mencoba SUBSTR 5 karakter pertama untuk kode pos.

— Gua Justin
sumber

4

Nah, dengan asumsi kita mengkodekan sesuatu yang konyol seperti Pro * C, memiliki bidang yang cukup besar untuk pertumbuhan berarti kode tidak perlu disentuh jika penggunaan meningkat.

— EvilTeach

Ya, memecah kode pos AS menjadi 5 dan 4 digit bisa saja masuk akal, tergantung untuk apa Anda berencana menggunakannya. Misalnya, jika Anda melakukan semacam pencocokan alamat, Anda mungkin ingin mencocokkan di zip5 terlebih dahulu, dan menyelesaikan situasi yang ambigue dengan zip 9. Ini juga membantu menggunakan kode negara

— EvilTeach

3

Apa yang Anda lewatkan adalah alasan mengapa Anda membutuhkan kode pos untuk ditangani secara khusus.

Jika Anda tidak benar-benar perlu BEKERJA dengan kode pos, saya sarankan untuk tidak mencemaskannya. Dengan bekerja, maksud saya melakukan pemrosesan khusus daripada hanya digunakan untuk mencetak label alamat dan sebagainya.

Cukup buat tiga atau empat bidang alamat VARCHAR2 (50) [misalnya] dan biarkan pengguna memasukkan apa pun yang mereka inginkan.

Apakah Anda benar - benar perlu mengelompokkan pesanan atau transaksi Anda dengan kode pos? Saya kira tidak, karena negara yang berbeda memiliki skema yang sangat berbeda untuk bidang ini.

— paxdiablo
sumber

Saya setuju. Menggunakan bidang VARCHAR2 kenyataannya adalah untuk bidang seperti kode pos itu benar-benar tidak masalah. Sedikit terlalu besar lebih baik daripada mengganggu satu pelanggan karena mereka tidak dapat memasukkan detailnya.

— Toby Allen

Dan varchars berguna karena database (setidaknya DB2) dapat mengoptimalkan penyimpanannya, sehingga tidak membuang ruang penyimpanan.

— paxdiablo

1

orang akan menunjukkan bahwa menyortir menurut negara dan kode pos akan menghasilkan tarif pos yang lebih murah di beberapa tempat.

— EvilTeach

10

Disgaree. Suatu saat nanti Anda akan memutuskan bahwa Anda harus memvalidasi alamat dalam database Anda (misalnya untuk mengoreksi kesalahan ketik dan entri data) dan saat itulah Anda akan menemukan manfaat dari membangun model data Anda dengan benar daripada hanya mendorong semuanya dalam ember.

— Gary Myers

1

@Pax Jika Anda menyerahkan surat massal ke Royal Mail yang diatur oleh kepala distrik (huruf pertama / dua huruf) dari kode pos, maka Anda dapat mengirimkannya melalui MailSort, yang lebih murah daripada surat kelas dua biasa. Itu hanya satu contoh.

— Richard Gadsden

3

Normalisasi? Kode pos mungkin digunakan lebih dari sekali, dan mungkin terkait dengan nama jalan atau nama kota. Tabel terpisah.

— Stephan Eggermont
sumber

Menarik. Sudut pandang yang berbeda hanya memberikan suara negatif tanpa alasan mengapa. +1

— EvilTeach

Kode pos biasanya merujuk pada sebuah blok di satu sisi jalan. Untuk menemukan wilayah yang lebih luas, Anda harus memilih paruh pertama kode pos. Memiliki informasi ini dalam tabel terpisah benar-benar tidak akan membantu apa pun dan akan lebih rumit untuk dikelola.

— RevNoah

4

@EvilTeach: Saya yakin itu tidak disukai karena di luar topik. Apakah ini memberi tahu Anda seberapa besar kolom yang seharusnya untuk menyimpan setiap kode pos yang mungkin ada di dunia? Tidak.

— wmax

2

Kode Pos Kanada hanya terdiri dari 6 karakter, berupa huruf dan angka (LNLNLN)

— tegbains
sumber

3

Kode pos Kanada ada yang kosong di tengah "ANA NAN" Artinya 7 karakter.

— EvilTeach

1

Tapi space nya selalu di tengah jadi tidak perlu disimpan.

— Graeme Perrow

1

Spasi tampaknya bukan bagian dari data: "Catatan: kode pos Kanada selalu diformat dalam urutan yang sama: karakter alfabet / angka / alfa / angka / alfa / angka (mis. K1A0B1)." Itu dari situs web Canada Post.

— tegbains

2

Saya tidak berpikir menghilangkan spasi ada hubungannya dengan 'normalisasi'. Ini hanya masalah tampilan. Seperti tanda hubung di nomor rekening. Saya tidak akan menyimpannya, dan saya tidak akan mengandalkannya untuk mengidentifikasi kode pos Kanada dalam preferensi ke bidang Kode Negara (int) yang dapat diindeks. Memisahkan lapisan Data dan Presentasi adalah cara yang tepat untuk melakukannya.

— Sam

2

Canada Post lebih menyukai spasi dalam kode pos saat menangani amplop. Yang terbaik adalah menyimpannya dengan spasi dan menangani validasi saat masuk.

— RevNoah

2

Inggris telah menerbitkan standar: Katalog Standar Data Pemerintah Inggris

Max 35 characters per line

Alamat Pos Internasional:

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

Panjang kode pos Inggris adalah:

Minimum 6 and Maximum 8 characters

— PodTech.io
sumber

1

Jika Anda ingin mengintegrasikan kode pos dalam database maka database geonames paling baik digunakan. Meskipun sulit untuk digunakan dan dipahami tetapi ini adalah basis data geografis terbesar yang tersedia secara gratis untuk pengguna seperti kami.

Semua basis data lainnya kemungkinan besar memiliki data dan struktur yang sama. Mereka hanya menghapus beberapa informasi ekstra / berlebihan dari database. Jika Anda hanya melakukannya untuk sistem beban rendah, gunakan layanan gratis mereka, batasannya menarik dan menyediakan antarmuka yang lebih mudah menggunakan json dan ajax. Anda dapat melihat batasannya di sini

Untuk informasi Anda, varchar (20) cukup untuk menyimpan kode pos

— Jay Kapasi
sumber