Bạn có nên sử dụng cột số nguyên để lưu trữ mã ZIP của Hoa Kỳ trong cơ sở dữ liệu không?

Question

Từ cái nhìn đầu tiên, nó sẽ xuất hiện tôi có hai lựa chọn cơ bản để lưu trữ ZIP codes trong một bảng cơ sở dữ liệu:

1. Text (có lẽ là phổ biến nhất), tức là char(5) hoặc varchar(9) để hỗ trợ 4 phần mở rộng
2. Numeric, tức là Số nguyên 32 bit

Cả hai đều đáp ứng các yêu cầu của dữ liệu, nếu chúng tôi cho rằng không có mối quan tâm quốc tế. Trong quá khứ chúng tôi thường chỉ đi theo con đường văn bản, nhưng tôi đã tự hỏi nếu có ai làm ngược lại? Chỉ cần so sánh ngắn gọn, có vẻ như phương pháp số nguyên có hai ưu điểm rõ ràng:

• Đó là, tự nhiên, chỉ giới hạn ở số học (trong khi không xác thực kiểu văn bản có thể lưu trữ chữ cái và chữ cái không theo kiến ​​thức của tôi, có giá trị trong mã ZIP). Điều này không có nghĩa là chúng tôi có thể/sẽ/nên bỏ qua xác nhận đầu vào người dùng như bình thường, mặc dù!
• Mất ít không gian hơn, là 4 byte (cần nhiều ngay cả đối với mã ZIP gồm 9 chữ số) thay vì 5 hoặc 9 byte.

Ngoài ra, có vẻ như nó sẽ không làm hỏng hiển thị nhiều đầu ra. Nó là tầm thường để tát một ToString() trên một giá trị số, sử dụng thao tác chuỗi đơn giản để chèn dấu nối hoặc dấu cách hoặc bất kỳ phần mở rộng +4 nào và sử dụng định dạng chuỗi để khôi phục số 0 đầu.

Có điều gì sẽ ngăn cản việc sử dụng int làm kiểu dữ liệu cho mã ZIP chỉ dành cho Hoa Kỳ không?

Answer 1

Mã ZIP số là - theo một cách nhỏ - gây hiểu nhầm.

Số điện thoại có nghĩa là số. Mã ZIP không thêm hoặc trừ hoặc tham gia vào bất kỳ thao tác số nào. 12309 - 12345 không tính toán khoảng cách từ trung tâm thành phố Schenectady đến vùng lân cận của tôi.

Đã cấp, cho mã ZIP, không ai bị nhầm lẫn. Tuy nhiên, đối với các trường giống số khác, nó có thể gây nhầm lẫn.

Vì mã ZIP không phải là số - chúng chỉ xảy ra được mã hóa với bảng chữ cái bị hạn chế - Tôi khuyên bạn nên tránh trường số. Tiết kiệm 1 byte không đáng giá nhiều. Và tôi nghĩ rằng nghĩa là quan trọng hơn byte.

---

Chỉnh sửa.

"Đối với các số 0 hàng đầu ..." là quan điểm của tôi. Các số không có số 0 đứng đầu. Sự hiện diện của các số 0 hàng đầu có ý nghĩa trên mã ZIP là một bằng chứng khác cho thấy chúng không phải là số.

Answer 2

Bạn có bao giờ lưu trữ mã bưu điện không phải của Hoa Kỳ không? Canada là 6 ký tự với một số chữ cái. Tôi thường chỉ sử dụng một trường 10 ký tự. Dung lượng ổ đĩa rẻ, phải làm lại mô hình dữ liệu của bạn thì không.

Answer 3

Sử dụng chuỗi có xác thực. Mã zip có thể bắt đầu bằng 0, vì vậy số không phải là loại phù hợp. Ngoài ra, điều này áp dụng gọn gàng với mã bưu chính quốc tế (ví dụ: Vương quốc Anh, tối đa 8 ký tự). Trong trường hợp không chắc rằng mã bưu điện là một nút cổ chai, bạn có thể giới hạn nó thành 10 ký tự, nhưng trước hết hãy kiểm tra số target formats của bạn.

Here are regexes xác thực cho Vương quốc Anh, Hoa Kỳ và Canada.

---

Có, bạn có thể nhấn để thu lại số 0 hàng đầu. Tuy nhiên, về mặt lý thuyết, bạn có thể loại bỏ thông tin có thể hữu ích trong trường hợp có lỗi. Nếu ai đó tìm thấy 1235 trong cơ sở dữ liệu, đó là ban đầu, hoặc có một chữ số khác bị bỏ qua?

Thực hành tốt nhất cho biết bạn nên nói những gì bạn muốn nói. Mã zip là mã, không phải là số. Bạn có đang truy cập vào add/subtract/multiply/divide mã zip không? Và từ quan điểm thực tế, điều quan trọng hơn nhiều là bạn không bao gồm các khóa mở rộng.

Answer 4

Số nguyên là tốt, nhưng nó chỉ hoạt động ở Hoa Kỳ, đó là lý do tại sao hầu hết mọi người không làm điều đó. Thông thường tôi chỉ sử dụng một varchar (20) hoặc hơn. Có lẽ quá mức cần thiết cho bất kỳ ngôn ngữ nào.

Answer 5

Thông thường, bạn sẽ sử dụng loại dữ liệu không phải số như một varchar cho phép nhiều loại mã zip hơn.Nếu bạn đã chết chỉ cho phép mã zip [XXXXX] hoặc 9 chữ số [XXXXX-XXXX] có chữ số gồm 5 chữ số, bạn có thể sử dụng char (5) hoặc char (10), nhưng tôi sẽ không khuyên bạn nên sử dụng nó. Varchar là sự lựa chọn an toàn nhất và lành mạnh nhất.

Chỉnh sửa: Cũng cần lưu ý rằng nếu bạn không có kế hoạch thực hiện các phép tính số trên trường, bạn không nên sử dụng loại dữ liệu số. Mã ZIP không phải là một số theo nghĩa bạn thêm hoặc trừ vào nó. Nó chỉ là một chuỗi xảy ra thường được tạo thành từ các con số, vì vậy bạn nên hạn chế sử dụng các kiểu dữ liệu số cho nó.

Answer 6

Từ quan điểm kỹ thuật, một số điểm được nêu ở đây khá tầm thường. Tôi làm việc với làm sạch dữ liệu địa chỉ trên cơ sở hàng ngày - trong dữ liệu địa chỉ làm sạch cụ thể từ khắp nơi trên thế giới. Nó không phải là một nhiệm vụ tầm thường bởi bất kỳ căng của trí tưởng tượng. Khi nói đến mã zip, bạn có thể lưu trữ chúng dưới dạng số nguyên mặc dù nó có thể không chính xác "ngữ nghĩa". Thực tế là, dữ liệu có dạng số dù có hay không, nói đúng là nó là được coi là số có giá trị. Tuy nhiên, nhược điểm thực sự của việc lưu trữ chúng dưới dạng kiểu số là bạn sẽ mất khả năng dễ dàng xem dữ liệu được nhập không chính xác (nghĩa là thiếu giá trị) hoặc nếu hệ thống loại bỏ các số 0 đứng đầu dẫn đến các hoạt động tốn kém để xác thực các mã zip không hợp lệ tiềm ẩn nếu không chính xác.

Cũng rất khó để buộc người dùng nhập dữ liệu chính xác nếu một trong những hậu quả là sự chậm trễ của doanh nghiệp. Người dùng thường không có đủ kiên nhẫn để nhập dữ liệu chính xác nếu dữ liệu đó không rõ ràng ngay lập tức. Sử dụng regex là một cách để đảm bảo dữ liệu chính xác, tuy nhiên nếu người dùng nhập giá trị không phù hợp và chúng hiển thị lỗi, họ có thể bỏ qua giá trị này hoàn toàn hoặc nhập nội dung phù hợp nhưng không chính xác. Một ví dụ [sử dụng mã bưu điện của Canada] là bạn thường thấy A0A 0A0 được nhập không hợp lệ nhưng phù hợp với regex cho mã bưu điện của Canada. Thường xuyên hơn không, điều này được nhập bởi người dùng bị buộc phải cung cấp mã bưu chính, nhưng họ không biết nó là gì hoặc không có tất cả chính xác.

Một đề xuất là xác thực toàn bộ mục nhập dưới dạng đơn vị xác thực rằng mã zip chính xác khi so sánh với phần còn lại của địa chỉ. Nếu không chính xác, khi đó cung cấp mã zip hợp lệ thay thế cho địa chỉ sẽ giúp họ nhập dữ liệu hợp lệ dễ dàng hơn.Tương tự như vậy, nếu mã zip là chính xác cho địa chỉ đường phố, nhưng số đường phố nằm ngoài miền của mã zip đó, sau đó cung cấp số đường phố thay thế cho kết hợp mã zip/đường phố đó.

Answer 7

Trừ khi bạn có yêu cầu nghiệp vụ để thực hiện các phép tính toán học trên dữ liệu mã ZIP, không có điểm nào khi sử dụng INT. Bạn đang trên kỹ thuật.

Hope this helps,

Bill

Answer 8

Nếu bạn đã sử dụng một số nguyên cho Dây khóa kéo Mỹ, bạn sẽ muốn nhân một phần hàng đầu bởi 10.000 và thêm 4. Mã hóa trong cơ sở dữ liệu không có gì để làm với xác thực đầu vào. Bạn luôn có thể yêu cầu đầu vào có giá trị hay không, nhưng dung lượng lưu trữ là vấn đề bạn nghĩ bao nhiêu yêu cầu của bạn hoặc USPS sẽ thay đổi. (Gợi ý: yêu cầu của bạn sẽ thay đổi.)

Answer 9

Mã ZIP thực sự là một không gian tên được mã hóa, nếu bạn nghĩ về nó. Theo truyền thống chữ số, mà còn là một dấu nối và vốn chữ:

"10022-GIÀY"

http://www.saksfifthavenue.com/main/10022-shoe.jsp

Thực tế, rất nhiều các ứng dụng doanh nghiệp sẽ không cần phải hỗ trợ trường hợp cạnh này, thậm chí nếu nó có giá trị .

Answer 10

Không, bởi vì

• Bạn không bao giờ làm chức năng toán học trên mã zip
• thể chứa dấu gạch ngang
• thể bắt đầu với 0
• giá trị NULL đôi khi hiểu là zero trong trường hợp của các loại vô hướng như số nguyên (ví dụ: khi bạn xuất dữ liệu bằng cách nào đó)
• Mã zip, ngay cả khi đó là số, là chỉ định của một khu vực, ý nghĩa này là một cái tên thay vì một số lượng số của bất cứ điều gì

Answer 11

tôi learned recently rằng trong Ruby một lý do bạn muốn tránh điều này là bởi vì có một số mã zip bắt đầu với zero hàng đầu, trong đó-nếu lưu trữ như trong số nguyên – sẽ tự động được chuyển đổi thành bát phân.

Từ the docs:

Bạn có thể sử dụng một tiền tố đặc biệt để viết số trong hệ thập phân, thập lục phân, bát phân hoặc các định dạng nhị phân. Đối với số thập phân, hãy sử dụng tiền tố 0d, cho số thập lục phân sử dụng tiền tố 0x, cho số bát phân sử dụng tiền tố 0 hoặc 0o…