Tôi cần lưu trữ mã bưu điện trong cơ sở dữ liệu. Cột phải lớn bao nhiêu?

103

Tôi mong đợi cột là một VARCHAR2, trong Cơ sở dữ liệu Oracle của tôi.

Zips của Hoa Kỳ là 9.

Người Canada là 7.

Tôi nghĩ 32 ký tự sẽ là giới hạn trên hợp lý

Tôi đang thiếu gì?

[EDIT] TIL: 12 là một câu trả lời hợp lý cho câu hỏi Cảm ơn mọi người đã đóng góp.

— EvilTeach
nguồn

Liên kết hữu ích, tuy nhiên độ chính xác của nó có thể hơi xa. EG nó liệt kê các mã bưu điện của Úc là 7 ký tự, trong khi thực tế là 4. Tham khảo: en.wikipedia.org/wiki/Postcodes_in_Australia và danh sách mã bưu điện có tại www1.auspost.com.au/postcodes .

— rossp

re: nhận xét trước đây của tôi - điều đó không có nghĩa là danh sách này không hữu ích như một hướng dẫn. Giả sử danh sách có lỗi ở bên cạnh các mã bưu điện dài hơn, độ dài dài nhất là 9 ký tự, vì vậy 16 ký tự hoặc khoảng trống sẽ cho bạn nhiều khoảng trống để thở.

— rossp

Danh sách quốc gia cũng hơi ngắn. Tôi chắc chắn có nhiều nước trên hành tinh ngoài danh mục ...

— Robert Koritnik

2

Theo en.wikipedia.org/wiki/List_of_postal_codes , dài nhất là 12 ký tự, nếu bạn đang lưu trữ '-', khác 11

— Neil McGuigan

@CMS: Bạn có thể muốn cập nhật liên kết đến trang wikipedia này , có vẻ như chi tiết hơn.

— Vajk Hermecz

51

Đọc lướt qua trang Mã Bưu điện của Wikipedia , 32 ký tự là quá đủ. Tôi có thể nói rằng thậm chí 16 ký tự là tốt.

— người đi lạc
nguồn

8

Liên kết tốt. Ngay cả khi cho phép dấu chấm câu ở US ZIP + 4, 10 ký tự sẽ là đủ cho bất kỳ quốc gia nào theo như tôi có thể nói.

— Jonathan Leffler

Dựa trên liên kết này, từ trang được liên kết ở trên, tôi sẽ đi với 18 người để phù hợp với các quốc gia như Chile: en.wikipedia.org/wiki/List_of_postal_codes

— mopo922

5

Chile là 7 ký tự. Trang web bạn đã tham chiếu chỉ hiển thị phương sai dấu câu.

— EvilTeach

21

Như đã được nêu ra bởi @ neil-mcguigan, wikipedia có một trang khá về chủ đề này. Dựa trên 12 ký tự đó nên làm điều đó: http://en.wikipedia.org/wiki/List_of_postal_codes

Bài báo wikipedia liệt kê ~ 254 quốc gia, khá tốt liên quan đến UPU (Liên minh Bưu chính Thế giới) có 192 quốc gia thành viên.

— Vajk Hermecz
nguồn

2

Lưu ý rằng Montserrat chỉ có 8 ký tự, 1110-1350 biểu thị một phạm vi. Discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Có thể Wikipedia cần chỉnh sửa vì mã bưu chính tương tự cho Malta có mã chung như "AAA NNNN". Tôi sẽ không phiền khi có thậm chí 15 ký tự vì nó chỉ có thể ít vấn đề hơn sau này nếu chúng ta phải điều chỉnh độ dài cột, cũng với việc sử dụng đúng kiểu dữ liệu, dù sao thì nó cũng không nên lấy tất cả 15 ký tự (có thể là varchar hoặc nvarchar hoặc tương tự?) .

— Manohar Reddy Poreddy

12

Tại sao bạn khai báo kích thước trường lớn hơn dữ liệu thực tế mà bạn đang mong đợi để lưu trữ trong đó?

Nếu phiên bản đầu tiên của ứng dụng của bạn sẽ hỗ trợ các địa chỉ Hoa Kỳ và Canada (mà tôi suy ra từ thực tế là bạn gọi ra các kích thước đó trong câu hỏi của mình), tôi sẽ khai báo trường là VARCHAR2 (9) (hoặc VARCHAR2 ( 10) nếu bạn định lưu trữ dấu gạch nối trong các trường ZIP + 4). Ngay cả khi xem xét các bài đăng mà những người khác đã thực hiện đối với mã bưu chính ở khắp các quốc gia, VARCHAR2 (9) hoặc VARCHAR2 (10) sẽ là đủ cho hầu hết các quốc gia khác.

Xuống dòng, bạn luôn có thể thay đổi cột để tăng chiều dài nếu cần. Nhưng nhìn chung rất khó để ngăn ai đó, ở đâu đó quyết định lấy "sáng tạo" và nhồi 50 ký tự vào trường VARCHAR2 (50) vì lý do này hay lý do khác (tức là vì họ muốn có một dòng khác trên nhãn vận chuyển). Bạn cũng phải đối phó với việc kiểm tra các trường hợp ranh giới (liệu mọi ứng dụng hiển thị ZIP sẽ xử lý 50 ký tự?). Và với thực tế là khi máy khách đang truy xuất dữ liệu từ cơ sở dữ liệu, họ thường cấp phát bộ nhớ dựa trên kích thước tối đa của dữ liệu sẽ được tìm nạp, không phải độ dài thực của một hàng nhất định. Có lẽ không phải là một vấn đề lớn trong trường hợp cụ thể này, nhưng 40 byte mỗi hàng có thể là một phần RAM phù hợp cho một số trường hợp.

Ngoài ra, bạn cũng có thể cân nhắc lưu trữ (ít nhất là đối với các địa chỉ ở Hoa Kỳ) mã ZIP và phần mở rộng +4 riêng biệt. Nhìn chung, rất hữu ích khi có thể tạo báo cáo theo khu vực địa lý và bạn có thể thường muốn đặt mọi thứ trong một mã ZIP với nhau hơn là chia nhỏ nó theo phần mở rộng +4. Tại thời điểm đó, sẽ hữu ích khi không phải cố gắng GỬI 5 ký tự đầu tiên cho mã ZIP.

— Hang động Justin
nguồn

4

Chà, giả sử chúng ta đang viết mã trong một thứ gì đó ngớ ngẩn như Pro * C, thì việc có trường đủ lớn để phát triển có nghĩa là mã sẽ không cần phải chạm vào nếu mức sử dụng tăng lên.

— EvilTeach

Có, việc chia mã zip của chúng tôi thành 5 và 4 chữ số có thể có ý nghĩa, tùy thuộc vào việc bạn định sử dụng nó để làm gì. Ví dụ, nếu bạn đang làm một số loại phù hợp với địa chỉ, bạn có thể muốn để phù hợp trên zip5 đầu tiên, và giải quyết các tình huống ambigueous với zip 9. Nó cũng giúp sử dụng một mã quốc gia

— EvilTeach

3

Những gì bạn đang thiếu là lý do tại sao bạn cần mã bưu chính được xử lý đặc biệt.

Nếu bạn không thực sự cần làm việc với mã bưu điện, tôi khuyên bạn không nên lo lắng về điều đó. Theo công việc, ý tôi là xử lý đặc biệt thay vì chỉ dùng để in nhãn địa chỉ, v.v.

Chỉ cần tạo ba hoặc bốn trường địa chỉ của VARCHAR2 (50) [ví dụ] và cho phép người dùng nhập bất kỳ thứ gì họ muốn.

Bạn có thực sự cần nhóm các đơn đặt hàng hoặc giao dịch của mình theo mã bưu điện không? Tôi nghĩ là không, vì các quốc gia khác nhau có những kế hoạch rất khác nhau cho lĩnh vực này.

— paxdiablo
nguồn

Tôi đồng ý. Sử dụng trường VARCHAR2, thực tế là đối với một trường như mã bưu điện thì điều đó thực sự không thành vấn đề. Hơi quá lớn sẽ tốt hơn là làm phiền một khách hàng vì họ không thể nhập chi tiết của họ.

— Toby Allen

Và các varchars rất tiện dụng vì cơ sở dữ liệu (ít nhất là DB2) có thể tối ưu hóa việc lưu trữ chúng, để không lãng phí không gian lưu trữ.

— paxdiablo

1

người ta sẽ chỉ ra rằng phân loại theo quốc gia và mã bưu chính sẽ dẫn đến giá bưu chính rẻ hơn ở một số nơi.

— EvilTeach

10

Không đồng ý. Đôi khi xuống dòng, bạn sẽ quyết định rằng bạn sẽ cần xác thực các địa chỉ trong cơ sở dữ liệu của mình (ví dụ: để sửa lỗi đánh máy và nhập dữ liệu) và đó là lúc bạn sẽ tìm thấy lợi ích của việc xây dựng đúng mô hình dữ liệu của mình thay vì chỉ đưa mọi thứ vào xô.

— Gary Myers

1

@Pax Nếu bạn chuyển thư số lượng lớn cho Royal Mail được sắp xếp trước bởi quận trưởng (chữ cái đầu tiên / hai chữ cái) của mã bưu điện, thì bạn có thể gửi thư bằng MailSort, rẻ hơn thư loại hai thông thường. Đó chỉ là một ví dụ.

— Richard Gadsden,

3

Chuẩn hóa? Mã bưu điện có thể được sử dụng nhiều lần và có thể liên quan đến tên đường hoặc tên thị trấn. (Các) bảng riêng biệt.

— Stephan Eggermont
nguồn

Hấp dẫn. Một quan điểm khác chỉ đơn giản là từ chối mà không có lý do tại sao. +1

— EvilTeach

Mã bưu điện thường sẽ tham chiếu đến một khối ở một bên của đường phố. Để tìm một vùng rộng hơn, bạn sẽ chọn nửa đầu của mã bưu điện. Có thông tin này trong một bảng riêng biệt thực sự sẽ không giúp được gì và sẽ phức tạp hơn để duy trì.

— RevNoah

4

@EvilTeach: Tôi cá là nó đã bị phản đối vì lạc đề. Nó có cho bạn biết một cột phải lớn như thế nào để lưu trữ mọi mã bưu chính có thể có trên thế giới? Không

— wmax

2

Mã bưu chính Canada chỉ có 6 ký tự, dưới dạng chữ cái và số (LNLNLN)

— tegbains
nguồn

3

Mã bưu chính của Canada có khoảng trống ở giữa "ANA NAN" Có 7 ký tự.

— EvilTeach

1

Nhưng khoảng trống luôn ở giữa nên bạn không cần cất giữ.

— Graeme Perrow

1

Khoảng trắng dường như không phải là một phần của dữ liệu: "Lưu ý: Mã bưu chính của Canada luôn được định dạng theo cùng một trình tự: ký tự chữ cái / chữ số / chữ cái / chữ số / chữ cái / chữ số (ví dụ: K1A0B1)." Đó là từ trang web Bưu điện Canada.

— tegbains

2

Tôi không nghĩ rằng việc bỏ qua không gian có liên quan gì đến 'bình thường hóa'. Nó chỉ là một vấn đề hiển thị. Giống như dấu gạch ngang trong số tài khoản. Tôi sẽ không lưu trữ nó và tôi sẽ không dựa vào nó để xác định các mã bưu điện của Canada thay vì trường CountryCode (int) có thể được lập chỉ mục. Phân tách dữ liệu và lớp trình bày là cách thích hợp để làm điều đó.

— Sam

2

Bưu điện Canada ưu tiên khoảng trống trong mã bưu điện khi giải quyết các phong bì. Tốt nhất là lưu trữ nó với không gian và xử lý xác thực khi nhập.

— RevNoah

2

Vương quốc Anh đã xuất bản các tiêu chuẩn: Danh mục Tiêu chuẩn Dữ liệu Chính phủ Vương quốc Anh

Max 35 characters per line

Địa chỉ Bưu điện Quốc tế:

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

Độ dài mã bưu chính của Vương quốc Anh là:

Minimum 6 and Maximum 8 characters

— PodTech.io
nguồn

1

Nếu bạn muốn tích hợp mã bưu điện trong cơ sở dữ liệu thì cơ sở dữ liệu địa lý là tốt nhất để sử dụng. Mặc dù nó khó sử dụng và hiểu được nhưng nó là cơ sở dữ liệu địa lý lớn nhất có sẵn miễn phí cho những người dùng như chúng tôi.

Tất cả các cơ sở dữ liệu khác như vậy ít nhiều có cùng dữ liệu và cấu trúc. Họ chỉ xóa một số thông tin thừa / thừa khỏi cơ sở dữ liệu. Nếu bạn chỉ làm điều đó cho các hệ thống tải thấp, hãy sử dụng các dịch vụ miễn phí của họ, các giới hạn này rất hấp dẫn và cung cấp giao diện dễ dàng hơn bằng cách sử dụng json và ajax. Bạn có thể xem các giới hạn tại đây

Đối với thông tin của bạn, varchar (20) là đủ để lưu trữ mã bưu điện

— Jay Kapasi
nguồn