Có thiết kế cơ sở dữ liệu địa chỉ đường phố chung cho tất cả các địa chỉ trên thế giới không?

Tôi là một lập trình viên và thành thật mà nói không biết cấu trúc địa chỉ đường phố trên thế giới, chỉ biết ở đất nước tôi được cấu trúc như thế nào :) vậy thiết kế cơ sở dữ liệu phổ biến và tốt nhất để lưu trữ địa chỉ đường phố là gì? Nó phải rất đơn giản để sử dụng, truy vấn nhanh và năng động để lưu trữ tất cả các địa chỉ đường phố trên thế giới được xác định chỉ bằng một id
Cảm ơn rất nhiều

Có thể đại diện cho các địa chỉ từ nhiều quốc gia khác nhau trong một tập hợp các trường tiêu chuẩn. Ý tưởng cơ bản về một tuyến đường tiếp cận được đặt tên (đường đi) mà các tòa nhà được đặt tên hoặc đánh số nằm trên đó là khá chuẩn, ngoại trừ đôi khi ở Trung Quốc. Các khái niệm gần như phổ biến khác bao gồm: đặt tên cho khu định cư (thành phố / thị trấn / làng), có thể được gọi chung là một địa phương; đặt tên khu vực và gán mã bưu điện gồm chữ và số. Lưu ý rằng mã bưu điện, còn được gọi là mã zip, chỉ hoàn toàn là số ở một số quốc gia. Bạn sẽ cần rất nhiều trường nếu bạn thực sự muốn trở nên chung chung.

Liên minh Bưu chính Thế giới UPU cung cấp dữ liệu địa chỉ cho nhiều quốc gia ở định dạng chuẩn . Lưu ý rằng định dạng UPU lưu giữ tất cả các địa chỉ (với độ chính xác trường khả dụng) cho cả một quốc gia, do đó nó có tính chất quan hệ. Nếu lưu trữ địa chỉ khách hàng, chỉ một phần nhỏ trong số tất cả các địa chỉ có thể được lưu trữ, tốt hơn hết là sử dụng một bảng (hoặc định dạng phẳng) chứa tất cả các trường và một địa chỉ trên mỗi hàng.

Một định dạng hợp lý để lưu trữ địa chỉ sẽ như sau:

• Dòng địa chỉ 1-4
• Địa phương
• Khu vực
• Mã bưu điện (hoặc mã vùng)
• Quốc gia

Dòng địa chỉ 1-4 có thể chứa các thành phần như:

• Xây dựng
• Tòa nhà phụ
• Số chính xác (số nhà)
• Phạm vi tiền đề
• Thông hành
• Đường phụ
• Khu dân cư phụ thuộc kép
• Tổ dân phố

Thường chỉ có 3 dòng địa chỉ được sử dụng, nhưng điều này thường không đủ. Tất nhiên có thể yêu cầu nhiều dòng hơn để đại diện cho tất cả các địa chỉ ở định dạng chính thức, nhưng dấu phẩy luôn có thể được sử dụng làm dấu phân cách dòng, có nghĩa là thông tin vẫn có thể được thu thập.

Thông thường, việc phân tích dữ liệu sẽ được thực hiện theo địa phương, khu vực, mã bưu điện và quốc gia và những yếu tố này khá dễ hiểu đối với người dùng khi nhập dữ liệu. Đây là lý do tại sao các phần tử này nên được lưu trữ dưới dạng các trường riêng biệt. Tuy nhiên, đừng ép buộc người dùng cung cấp mã bưu điện hoặc khu vực, chúng có thể không được sử dụng cục bộ.

Vị trí có thể không rõ ràng, đặc biệt là sự phân biệt giữa địa phương bản đồ và địa phương bưu điện. Địa phương bưu chính là địa phương được coi là của cơ quan bưu điện, đôi khi có thể là một thị trấn lớn gần đó. Tuy nhiên, mã bưu điện thường sẽ giải quyết mọi vấn đề hoặc sự khác biệt ở đó, để cho phép gửi chính xác ngay cả khi bưu cục chính thức không được sử dụng.

Hãy xem câu trả lời cơ sở dữ liệu . Cụ thể, điều này bao gồm nhiều trường hợp:

(Tất cả kiểu dữ liệu ký tự có độ dài thay đổi)

AddressId
Line1
Line2
Line3
City
ZipOrPostcode
StateProvinceCounty
CountryId
OtherAddressDetails

Hãy tự hỏi mục đích chính của việc lưu trữ dữ liệu này là gì? Bạn có định thực sự gửi thư cho người đó theo địa chỉ không? Theo dõi nhân khẩu, dân số? Có thể yêu cầu người gọi cung cấp địa chỉ chính xác của họ như một phần của một số xác thực / xác minh cơ bản không? Tất cả những điều trên? Không có cái nào ở trên?

Tùy thuộc vào nhu cầu thực tế của bạn, bạn sẽ xác định a) điều đó không thực sự quan trọng và bạn có thể sử dụng cách tiếp cận văn bản tự do hoặc b) các trường có cấu trúc / cụ thể cho tất cả các quốc gia, hoặc c) kiến ​​trúc cụ thể của quốc gia.

Đôi khi nơi gần nhất bạn có thể đến một địa chỉ đường phố là thành phố.

Tôi đã từng có một dự án đưa tất cả các trường Trung học ở Ấn Độ vào Google Maps. Tôi đã viết một chương trình phức tạp bằng cách sử dụng Google API và nghĩ rằng nó sẽ khá dễ dàng.

Sau đó, tôi nhận được dữ liệu từ khách hàng. Một số địa chỉ trường học như "Đối diện với chợ, cạnh tiệm cắt tóc" hoặc "Gần trạm xe buýt cũ".

Nó làm cho nhiệm vụ của tôi khó khăn hơn nhiều vì rất tiếc, Google API không hỗ trợ định dạng đó.

Đối với các địa chỉ quốc tế, rất khó để tìm ra cách định dạng thông tin nếu nó được chia thành các trường. Ví dụ, một địa chỉ tiếng Ý sử dụng:

<street address>
<zip> <town> <region>
<country>

Nhu la

Via Eroi della Repubblica
89861 Tropea VV
Italy

Điều đó khá khác với thứ tự cho địa chỉ Hoa Kỳ - trên dòng thứ hai.

Xem thêm các câu hỏi SO:

• Bạn sẽ sử dụng bao nhiêu trường địa chỉ cho cơ sở dữ liệu ở Vương quốc Anh?
• Bạn có chia nhỏ các địa chỉ thành phố / thành phố / bang / zip không?
• Làm thế nào để bạn đối phó với các hậu tố đường phố trùng lặp?
• 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ũng kiểm tra thẻ ' mã bưu chính '.

Chỉnh sửa : Đảo ngược thứ tự của khu vực và thị trấn - theo UPU

Có thể điều này hữu ích: https://gist.github.com/259744 Đối với một dự án, tôi đã thu thập một bảng thông tin về tất cả các quốc gia trên thế giới, bao gồm mã ISO, miền cấp cao nhất, mã điện thoại, ký hiệu xe hơi, chiều dài và regex của zip. Rất tiếc, tên quốc gia và bình luận chỉ bằng tiếng Đức ...

Phụ thuộc vào cách bạn chuẩn bị cho các trường ở dạng tự do. Một trường địa chỉ dạng tự do rõ ràng sẽ luôn luôn làm được, nhưng tương đối ít giúp thu hẹp địa lý.

Vấn đề bạn sẽ gặp phải là có quá nhiều khác biệt về mức độ phân cấp địa lý giữa các quốc gia. Rất tiếc, một số quốc gia thậm chí không có 'địa chỉ đường phố' ở khắp mọi nơi.

Tôi khuyên bạn không nên cố gắng làm cho nó quá thông minh.

Khác với các câu trả lời khác ở đây, tôi tin rằng có thể có một cơ sở dữ liệu địa chỉ có cấu trúc.

Chỉ cần ra khỏi cái mũ, tôi có thể nghĩ ra cấu trúc sau:

• Quốc gia
• Vùng (Bang / Tỉnh)
• Địa phương (Thành phố / Đô thị)
• Cụm dân cư (Hạt / bộ phận phụ khác của một địa phương)
• đường phố

Nhưng làm thế nào để truy vấn nó đủ nhanh?

Một cách mà tôi luôn nghĩ rằng nó có thể được thực hiện là yêu cầu Mã ZIP (hoặc Mã Bưu điện) khác nhau giữa các quốc gia, nhưng phải chắc chắn trong phạm vi quốc gia.

Bằng cách này, bạn có thể cấu trúc dữ liệu của mình xung quanh thông tin được cung cấp bởi các bưu điện trên thế giới.

Len Silverston nổi tiếng về Mô hình Dữ liệu Phổ thông đề xuất một hệ thống phân cấp riêng biệt GEOGRAPHIC BOUNDARIESvà tùy thuộc vào mức độ tự do mà bạn sẵn sàng chấp nhận hoặc STREET ADDRESS LINEcác dẫn xuất đơn giản theo từng quốc gia.

Không, hoàn toàn không. Nếu bạn so sánh cách hoạt động của các địa chỉ Hoa Kỳ và Nhật Bản , bạn sẽ thấy rằng điều đó là không thể.

CẬP NHẬT:

Suy nghĩ thứ hai, bất cứ điều gì có thể được thực hiện, nhưng cần phải đánh đổi.

Một cách tiếp cận là mô hình hóa vấn đề với các bảng address và address_attribute, với mối quan hệ 1: m giữa chúng, mọi thứ đều có thể được mô hình hóa. Bảng address_attribute sẽ có pk, tên, giá trị và fk trỏ về pk của địa chỉ cha của nó. Nó gần giống như sử dụng Bản đồ với các cặp tên, giá trị.

Đánh đổi là bạn phải THAM GIA mỗi khi bạn muốn có địa chỉ. Bạn cũng phải thẩm vấn tên của address_attributes để tìm ra những gì bạn đang xử lý mỗi lần.

Một cách tiếp cận khác là thực hiện nghiên cứu toàn diện hơn về cách các địa chỉ được mô hình hóa trên khắp thế giới. Trong thế giới hướng đối tượng, bạn có thể có lớp Địa chỉ phía tây (street1 / street2 / city / state / zip) và các lớp khác cho Nhật Bản, Trung Quốc, nếu cần để xếp không gian địa chỉ. Sau đó, bạn sẽ có một bảng Địa chỉ chính và các bảng con cho các loại khác với mối quan hệ 1: 1 giữa chúng.

Amazon hoặc eBay làm điều đó như thế nào? Họ vận chuyển quốc tế. Họ có các tính năng giao diện người dùng theo ngôn ngữ cụ thể không? Tôi chỉ sử dụng ngôn ngữ Hoa Kỳ.

Không, không có sơ đồ địa chỉ tiêu chuẩn. Nó thường khác nhau giữa các quốc gia. Ngay cả Liên minh Bưu chính Thế giới cũng cho biết trên Adress the world, một địa chỉ cho tất cả mọi người rằng không có. Giải pháp tốt nhất cho điều này là sử dụng tiêu chuẩn mã quốc gia 2/3 ký tự được gọi là ISO 3166 và xử lý mọi thứ khác theo tiêu chuẩn quốc gia.

Tuy nhiên, nếu bạn thực sự muốn sử dụng các công cụ dễ truy cập cho dự án của mình, bạn có thể thử Google Place API .

Thiết kế của bạn nên phụ thuộc nhiều vào mục đích của bạn. Một số người đã đăng cách cấu trúc dữ liệu. Vì vậy, nếu bạn chỉ muốn gửi s-mail cho ai đó, nó sẽ làm được. Mọi thứ bắt đầu phức tạp nếu bạn muốn sử dụng dữ liệu này để điều hướng. Điều hướng ô tô sẽ yêu cầu cấu trúc bổ sung để chứa thông tin giao thông (ví dụ: đường một chiều), trong khi điều hướng bằng chân sẽ yêu cầu nhiều dữ liệu bổ sung. Đây là một ví dụ nhỏ: trong thành phố của tôi, khu phố của tôi gần công viên. Bên cạnh công viên là sân bay trước đây (trên thực tế, một trong những sân bay lâu đời nhất ở châu Âu) được biến thành bảo tàng hàng không. Bên cạnh bảo tàng hàng không là một công viên kinh doanh. Số đường của bảo tàng là 39, trong khi số của khu thương mại bắt đầu bằng 39A. Vì vậy, có vẻ như 39 và 39A gần nhau - nhưng phải mất khoảng một dặm để đi bộ từ nơi này đến nơi khác (và thậm chí lâu hơn nếu đi ô tô).
Đây chỉ là một ví dụ nhỏ được lấy từ thành phố của tôi, tôi nghĩ bạn có thể tìm thấy rất nhiều trường hợp ngoại lệ (đặc biệt là ở các vùng nông thôn hoặc vùng hoang dã của mọi quốc gia).