Cách "tốt nhất" để lưu trữ địa chỉ quốc tế trong cơ sở dữ liệu là gì? Trả lời dưới dạng lược đồ và giải thích lý do tại sao bạn chọn bình thường hóa (hay không) theo cách bạn đã làm. Đồng thời giải thích lý do bạn chọn loại và độ dài của từng trường.Cách "tốt nhất" để lưu trữ địa chỉ quốc tế trong cơ sở dữ liệu là gì?
Lưu ý: Bạn quyết định trường nào bạn cho là cần thiết.
Văn bản dạng tự do thuần túy.
Xác thực tất cả các mã bưu chính/mã zip của thế giới quá khó; một danh sách cố định các quốc gia quá nhạy cảm về mặt chính trị; tiểu bang bắt buộc/khu vực/phân khu hành chính khác chỉ đơn giản là không phù hợp (tất cả các quá thường tôi được hỏi quận tôi sống ở đâu - khi tôi không, bởi vì Greater London không phải là một quận ở tất cả).
Thêm vào vấn đề, đơn giản là không cần thiết. Ứng dụng của bạn rất khó có thể mô hình hóa địa chỉ theo bất kỳ cách nghiêm túc nào. Nếu bạn muốn có địa chỉ bưu điện, hãy yêu cầu địa chỉ bưu điện. Hầu hết mọi người không ngu ngốc như vậy để đưa vào một cái gì đó khác hơn là một địa chỉ bưu chính, và nếu họ làm, họ có thể hôn tạm biệt mục mới mua của họ.
Ngoại lệ cho điều này là nếu bạn đang làm điều gì đó tự nhiên bị hạn chế ở một quốc gia. Trong trường hợp này, bạn nên yêu cầu, ví dụ, cặp {mã bưu điện, số nhà}, đủ để xác định địa chỉ bưu chính. Tôi tưởng tượng bạn có thể đạt được những điều tương tự với mã zip mở rộng ở Mỹ.
Đại Luân Đôn có thể không phải là hạt nhưng trừ khi bạn sống trong chính Thành phố Luân Đôn, có thể bạn sẽ thấy rằng bạn thực sự sống ở Surrey, Kent, Essex hoặc những nơi tương tự. – belugabob
Việc đặt các phân mục quản trị khác nhau rất tiện lợi cho việc lọc theo vùng. Làm thế nào khác bạn sẽ biết phần nào của thế giới/quốc gia bạn bán hầu hết các sản phẩm? –
Tốt nhất, hãy chọn quốc gia. Các quốc gia chỉ được tạo thường xuyên. – DrPizza
Bạn cần cung cấp thêm một chút chi tiết về cách bạn định sử dụng dữ liệu. Ví dụ: các trường như Thành phố, Tiểu bang, Quốc gia có thể là văn bản trong bảng đơn hoặc là các mã được liên kết với một bảng riêng biệt có Khóa ngoại.
đơn giản nhất sẽ là
Address_Line_01 (Bắt buộc, không trống) Address_Line_02 Address_Line_03 Landmark City (Bắt buộc) Pin (Bắt buộc) Province_District Nhà nước (Bắt buộc) Quốc gia (Bắt buộc)
Tất cả những điều trên có thể là Text/Unicode với độ dài trường thích hợp.
Số điện thoại nếu có.
Chỉ một loạt các quốc gia có trạng thái. –
Trước đây tôi đã lập biểu mẫu các biểu mẫu cần thiết quốc tế sau các biểu mẫu địa chỉ giao hàng up/fedex trên trang web của họ (tôi biết nếu họ không biết cách xử lý đơn đặt hàng quốc tế, tất cả chúng tôi đều được chào). Các trường họ sử dụng có thể được sử dụng làm tài liệu tham khảo để thiết lập lược đồ của bạn.
Nói chung, bạn cần phải hiểu tại sao bạn muốn có địa chỉ. Là nó cho vận chuyển/gửi thư? Sau đó, thực sự chỉ có một yêu cầu, có quốc gia riêng biệt. Các dòng khác là dạng tự do, được người dùng điền vào. Lý do cho điều này là chiến lược chuyển tiếp chung cho thư: bất kỳ thư đến nào cho một quốc gia nước ngoài được chuyển tiếp mà không cần nhìn vào các dòng địa chỉ khác. Do đó, thông tin chi tiết được phân tích cú pháp chỉ bởi bộ phân phối thư nằm trong chính quốc gia đó. Giống như người nhận, họ sẽ quen thuộc với các công ước quốc gia.
(UPS có thể kết hợp với một số quốc gia châu Âu nhỏ, vv .. tất cả các nước thấp có thể được phục vụ từ Bỉ - ý tưởng vẫn giữ.)
Bạn có cơ hội có nghĩa là "gửi đi" thay vì "đến" không? – rinogo
Tôi nghĩ rằng việc thêm văn bản quốc gia/thành phố và địa chỉ sẽ ổn. quốc gia và thành phố phải tách biệt để báo cáo. Người quản lý luôn luôn yêu cầu các loại báo cáo mà bạn không mong đợi và tôi không thích chạy truy vấn LIKE thông qua cơ sở dữ liệu lớn.
Không được tôn trọng Facebook. Tuy nhiên, cấu trúc tổng thể của cơ sở dữ liệu dường như bị bỏ qua trong nhiều ứng dụng web khởi chạy mỗi ngày. Rõ ràng tôi không nghĩ rằng có một giải pháp hoàn hảo bao gồm tất cả các biến tiềm năng với cấu trúc địa chỉ mà không có một số công việc khó khăn. Điều đó nói rằng, kết hợp với tự động hoàn thành Facebook quản lý để lấy dữ liệu đầu vào vị trí và loại bỏ phần lớn các mục dự phòng của chúng. Họ làm điều này bằng cách tổ chức cơ sở dữ liệu của họ đủ tốt để cung cấp thông tin tự động hoàn thành với chi phí thấp, cách lỗi thấp cho khách hàng trong thời gian thực cho phép họ chọn ít hoặc nhiều vị trí chính xác từ danh sách hiện có.
Tôi nghĩ giải pháp tốt nhất là truy cập cơ sở dữ liệu của bên thứ ba chứa phạm vi địa lý mong muốn của bạn và sử dụng nó để ban đầu gieo hạt thông tin vị trí người dùng của bạn. Điều này sẽ cho phép bạn tránh làm các công việc của riêng bạn. Với bất kỳ may mắn nào bạn có thể giảm tải trên máy chủ của mình bằng cách cho phép người dùng mới của bạn nhận được thông tin tự động điền chính xác trực tiếp từ nhà cung cấp bên thứ ba của bạn. Cuối cùng, bạn sẽ có thể điền vào hầu hết các thông tin vị trí như thành phố, quốc gia, v.v. từ thông tin chứa trong cơ sở dữ liệu của riêng bạn từ dữ liệu đầu vào của người dùng.
Tôi đã nói về năm ngoái! [Địa chỉ trong cơ sở dữ liệu] (http://mojoai.blogspot.com/2010/12/addresses-in-databases.html) –
Mã bưu điện có thể phức tạp - ví dụ, không có hệ thống mã bưu điện chung ở Cộng hòa Ireland, mặc dù mã bưu điện tồn tại cho Dublin (tất cả được đánh số 1-24, ngoại trừ 6W). – Geoglyph
Sau cuộc thảo luận có thể giúp .. http://stackoverflow.com/questions/1159756/how-should-international-geographical-addresses-be-stored-in-a-relational-databa – chandraP