Các phương pháp hay nhất để lưu trữ địa chỉ bưu điện trong cơ sở dữ liệu (RDBMS)?

Có bất kỳ tài liệu tham khảo tốt nào về các phương pháp hay nhất để lưu trữ địa chỉ bưu điện trong RDBMS không? Có vẻ như có rất nhiều sự cân bằng có thể được thực hiện và rất nhiều ưu và nhược điểm cho mỗi thứ cần được đánh giá - chắc chắn điều này đã được thực hiện hết lần này đến lần khác? Có lẽ ai đó đã viết ít nhất thực hiện một số bài học kinh nghiệm ở đâu đó?

Ví dụ về sự cân bằng mà tôi đang nói đến là lưu trữ mã zipcode dưới dạng số nguyên so với trường char, số nhà nên được lưu trữ dưới dạng trường riêng biệt hoặc một phần của dòng địa chỉ 1, số suite / căn hộ / v.v. có được chuẩn hóa hay chỉ được lưu trữ dưới dạng đoạn văn bản trong dòng địa chỉ 2, làm thế nào để bạn xử lý zip +4 (các trường riêng biệt hoặc một trường lớn, số nguyên so với văn bản)? Vân vân.

Tôi chủ yếu quan tâm đến các địa chỉ ở Hoa Kỳ vào thời điểm này nhưng tôi tưởng tượng có một số phương pháp hay nhất liên quan đến việc chuẩn bị cho bản thân trước tình huống phát triển ra toàn cầu (ví dụ: đặt tên các trường một cách thích hợp như vùng thay vì tiểu bang hoặc mã bưu điện thay vì mã zip, Vân vân.

Để sử dụng quốc tế nhiều hơn, một lược đồ cần xem xét là lược đồ được sử dụng bởi Trường địa chỉ Drupal . Nó dựa trên tiêu chuẩn xNAL và dường như bao gồm hầu hết các trường hợp quốc tế. Đào sâu một chút vào mô-đun đó sẽ tiết lộ một số viên ngọc trai tốt để diễn giải và xác thực địa chỉ trên phạm vi quốc tế. Nó cũng có một loạt các khu vực hành chính (tỉnh, bang, oblast, v.v.) với mã ISO.

Đây là ý chính của lược đồ, được sao chép từ trang mô-đun:

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)

Một bài học tôi đã học được:

• Đừng lưu trữ bất cứ thứ gì ở dạng số.
• Lưu trữ quốc gia và khu vực hành chính dưới dạng mã ISO nếu có thể.
• Khi bạn không biết, hãy lỏng lẻo trong việc yêu cầu các trường. Một số quốc gia có thể không sử dụng các trường bạn cho là đương nhiên, ngay cả những thứ cơ bản như locality& thoroughfare.

Là một người dùng 'quốc tế', không có gì khó chịu hơn việc phải đối mặt với một trang web chỉ xoay quanh các địa chỉ định dạng Hoa Kỳ. Thoạt đầu, nó hơi thô lỗ, nhưng sẽ trở thành một vấn đề nghiêm trọng khi việc xác nhận cũng quá sốt sắng.

Nếu bạn lo lắng về việc vươn ra toàn cầu, lời khuyên duy nhất mà tôi có là giữ mọi thứ ở dạng tự do. Các quốc gia khác nhau có những quy ước khác nhau - một số thì số nhà đứng trước tên đường, một số thì lại đứng sau. Một số có tiểu bang, một số khu vực, một số quận, một số kết hợp của chúng. Ở Vương quốc Anh, mã vùng không phải là mã vùng, mà là mã bưu điện chứa cả chữ cái và số.

Tôi chỉ khuyên đơn giản là ~ 10 dòng chuỗi có độ dài thay đổi, cùng với một trường riêng biệt cho mã bưu điện (và hãy cẩn thận cách bạn mô tả điều đó để đối phó với sự nhạy cảm của quốc gia). Hãy để người dùng / khách hàng quyết định cách viết địa chỉ của họ.

Nếu bạn cần thông tin đầy đủ về cách các quốc gia khác sử dụng địa chỉ bưu điện, đây là một liên kết tham khảo rất tốt (Đại học Columbia):

Hướng dẫn bắt buộc của Frank về địa chỉ bưu điện Cách
giải quyết hiệu quả cho thư quốc tế

Bạn chắc chắn nên xem xét việc lưu trữ số nhà dưới dạng trường ký tự thay vì số, vì các trường hợp đặc biệt như "số nửa" hoặc địa chỉ hiện tại của tôi, giống như "129A" ​​- nhưng chữ A không được coi là căn hộ số cho các dịch vụ giao hàng.

Tôi đã làm điều này (mô hình hóa cấu trúc địa chỉ một cách chặt chẽ trong cơ sở dữ liệu) và tôi sẽ không bao giờ làm điều đó nữa. Bạn không thể tưởng tượng được mức độ điên rồ của các trường hợp ngoại lệ mà bạn sẽ phải tính đến như một quy tắc.

Tôi mơ hồ nhớ lại một số vấn đề với mã bưu chính của Na Uy (tôi nghĩ), có tất cả 4 vị trí, ngoại trừ Oslo, có 18 hoặc lâu hơn.

Tôi chắc chắn rằng kể từ thời điểm chúng tôi bắt đầu sử dụng mã ZIP chính xác về mặt địa lý cho tất cả các địa chỉ quốc gia của chúng tôi, khá nhiều người đã bắt đầu phàn nàn rằng thư của họ đến quá muộn. Hóa ra những người đó đang sống gần ranh giới giữa các khu vực bưu điện, và mặc dù thực tế là ai đó thực sự sống trong khu vực bưu điện, chẳng hạn như 1600, trên thực tế, thư của anh ta nên được gửi đến khu vực bưu điện 1610, bởi vì thực tế đó là khu vực bưu chính lân cận đó điều đó thực sự phục vụ anh ta, vì vậy việc gửi thư của anh ta đến đúng khu vực bưu chính của anh ta sẽ mất vài ngày nữa để đến nơi, do sự can thiệp không mong muốn được yêu cầu ở đúng bưu điện để chuyển nó đến khu vực bưu chính không chính xác ...

(Chúng tôi đã kết thúc việc đăng ký những người đó có địa chỉ ở nước ngoài trong nước với mã ISO 'ZZ'.)

Bạn chắc chắn nên tham khảo " Đây có phải là một cách tốt để lập mô hình thông tin địa chỉ trong cơ sở dữ liệu quan hệ ", nhưng câu hỏi của bạn không phải là bản sao trực tiếp của điều đó.

Chắc chắn có rất nhiều câu trả lời đã có từ trước (xem các mô hình dữ liệu mẫu tại DatabaseAnswers ). Nhiều câu trả lời tồn tại trước bị lỗi trong một số trường hợp (hoàn toàn không chọn các câu trả lời trên DB).

Một vấn đề chính cần xem xét là phạm vi của các địa chỉ. Nếu cơ sở dữ liệu của bạn phải xử lý các địa chỉ quốc tế, bạn phải linh hoạt hơn so với việc bạn chỉ phải xử lý các địa chỉ ở một quốc gia.

Theo quan điểm của tôi, thường (không có nghĩa là luôn luôn ) hợp lý khi vừa ghi lại 'hình ảnh nhãn địa chỉ' của địa chỉ và phân tích riêng nội dung. Điều này cho phép bạn giải quyết sự khác biệt giữa vị trí đặt mã bưu điện, chẳng hạn như giữa các quốc gia khác nhau. Chắc chắn, bạn có thể viết một trình phân tích và một công cụ định dạng để xử lý những điểm lập dị của các quốc gia khác nhau (ví dụ: địa chỉ Hoa Kỳ có 2 hoặc 3 dòng; ngược lại, địa chỉ Anh có thể có nhiều hơn đáng kể; một địa chỉ tôi viết cho định kỳ có 9 dòng). Nhưng có thể dễ dàng hơn nếu con người thực hiện phân tích và định dạng và để DBMS chỉ lưu trữ dữ liệu.

Trừ khi bạn định làm toán về số đường phố hoặc mã zip / mã bưu chính, bạn chỉ đang mời gọi những nỗi đau trong tương lai bằng cách lưu trữ chúng dưới dạng số.

Bạn có thể tiết kiệm một vài byte ở đây và ở đó, và có thể nhận được chỉ mục nhanh hơn, nhưng bạn sẽ làm gì khi bưu chính Hoa Kỳ, hoặc bất kỳ quốc gia nào khác mà bạn đang giao dịch, quyết định giới thiệu alphas vào mã?

Chi phí dung lượng ổ đĩa sẽ rẻ hơn rất nhiều so với chi phí sửa chữa nó sau này ... y2k ai?

Thêm vào những gì @ Jonathan Leffler và @ Paul Fisher đã nói

Nếu bạn từng dự đoán có thêm địa chỉ bưu điện cho Canada hoặc Mexico vào yêu cầu của mình, thì việc lưu trữ postal-codedưới dạng chuỗi là điều bắt buộc. Canada có các mã bưu chính gồm chữ và số và tôi không nhớ rõ Mexico trông như thế nào.

Ive nhận thấy rằng liệt kê tất cả các trường có thể có từ đơn vị rời rạc nhỏ nhất đến lớn nhất là cách dễ nhất. Người dùng sẽ điền vào các trường mà họ thấy phù hợp. Bảng địa chỉ của tôi trông như thế này:

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

Đâu là "đánh đổi" trong việc lưu trữ ZIP dưới dạng NUMBER hoặc VARCHAR? Đó chỉ là một sự lựa chọn - nó không phải là sự đánh đổi trừ khi có lợi cho cả hai và bạn phải từ bỏ một số lợi ích để có được người khác.

Trừ khi tổng số các khóa kéo có bất kỳ ý nghĩa nào, các khóa kéo dưới dạng số không hữu ích.

Đây có thể là một sự quá mức cần thiết, nhưng nếu bạn cần một giải pháp có thể hoạt động với nhiều quốc gia và bạn cần phải xử lý theo chương trình các phần của địa chỉ:

bạn có thể xử lý địa chỉ quốc gia cụ thể bằng cách sử dụng hai bảng: Một bảng chung với 10 cột VARCHAR2, 10 cột Số, một bảng khác ánh xạ các trường này tới lời nhắc và có một cột quốc gia liên kết cấu trúc địa chỉ với một quốc gia.

Nếu bạn phải xác minh một địa chỉ hoặc sử dụng nó để xử lý các khoản thanh toán bằng thẻ tín dụng, ít nhất bạn sẽ cần một cấu trúc nhỏ. Một khối văn bản dạng tự do không hoạt động tốt cho điều đó.

Mã zip là trường tùy chọn phổ biến để xác thực các giao dịch thẻ thanh toán mà không cần sử dụng toàn bộ địa chỉ. Vì vậy, hãy có một trường riêng biệt và có kích thước rộng rãi cho trường đó (ít nhất 10 ký tự).

Lấy cảm hứng từ Câu trả lời cơ sở dữ liệu

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Tôi sẽ chỉ đặt tất cả các trường lại với nhau trong một trường NVARCHAR (1000) lớn, với một phần tử textarea để người dùng nhập giá trị cho (trừ khi bạn muốn thực hiện phân tích trên mã zip). Tất cả những đầu vào dòng địa chỉ 1, dòng địa chỉ 2, v.v. thật khó chịu nếu bạn có địa chỉ không phù hợp với định dạng đó (và bạn biết đấy, có những quốc gia khác ngoài Hoa Kỳ).