Что такое "best" способ хранения международных адресов в базе данных?

Обычный текст свободной формы.

Проверка всех мировых почтовых индексов/zip слишком сложна; фиксированный список стран слишком политически чувствителен; обязательное административное подразделение state/region/other просто неуместно (слишком часто меня спрашивают, в каком графстве я живу,когда я этого не делаю, потому что Большой Лондон вообще не является графством).

Более того, в этом просто нет необходимости. Очень маловероятно, что ваше приложение будет каким-либо серьезным образом моделировать адреса. Если вам нужен почтовый адрес, попросите его указать. Большинство людей не настолько глупы, чтобы написать что-то еще, кроме почтового адреса, и если они это сделают, то могут поцеловать свой недавно купленный товар на прощание.

Исключение из этого правила-если вы делаете что-то, что естественным образом связано с одной страной в любом случае. В этой ситуации вы должны попросить, скажем, пару { почтовый индекс, номер дома}, которой достаточно для идентификации почтового адреса. Я полагаю, что вы могли бы достичь подобных вещей с расширенным кодом zip в US.

В прошлом я моделировал формы, которые должны были быть международными после формуляров адреса доставки ups/fedex на их веб-сайтах (я полагал, что если они не знают, как обращаться с международным заказом, мы все обливаемся из шланга). Используемые ими поля можно использовать в качестве справочных для настройки схемы.

В общем, вам нужно понять, зачем вам нужен адрес. Это для shipping/mailing? тогда действительно есть только одно требование, чтобы страна была отдельной. Остальные строки имеют свободную форму и заполняются пользователем. Причина этого заключается в распространенной стратегии пересылки почты : любая входящая почта для другой страны пересылается, не глядя на другие адресные строки. Следовательно, детальная информация анализируется только сортировщиком почты, расположенным в самой стране. Как и приемник, они будут знакомы с национальными конвенциями.

(UPS может объединять некоторые небольшие европейские страны, например.. все нижние страны, вероятно, обслуживаются из Бельгии - идея все еще держится.)

Не оказывать Facebook чрезмерного уважения. Однако общая структура базы данных, по-видимому, не учитывается во многих веб-приложениях, запускаемых каждый день. Очевидно, я не думаю, что существует идеальное решение, которое охватывает все потенциальные переменные с адресной структурой без некоторой тяжелой работы. Тем не менее, в сочетании с автозаполнением Facebook удается взять входные данные местоположения и устранить большинство их избыточных записей. Они делают это, организуя свою базу данных достаточно хорошо, чтобы обеспечить автозаполнение информации в низкой стоимости, низкой ошибки пути к клиенту в режиме реального времени, что позволяет им более или менее выбрать правильное местоположение из существующего списка.

Я думаю, что лучшее решение-это получить доступ к базе данных третьей стороны, которая содержит желаемую географическую область, и использовать ее для первоначального заполнения информации о местоположении пользователя. Это позволит вам избежать выполнения груд-работ по созданию своих собственных. Если Вам повезет, вы можете уменьшить нагрузку на ваш сервер, позволив вашим новым пользователям получать правильную информацию о автозаполнении непосредственно от вашего стороннего поставщика. В конечном итоге вы сможете заполнить большинство автозаполнения для информации о местоположении, таких как город, страна и т.д. из информации, содержащейся в вашей собственной базе данных, из входных данных пользователя.

Я думаю, что добавление текста страны/города и адреса будет хорошо. страна и город должны быть разделены для отчетности. Менеджеры всегда запрашивают такие отчеты, которые вы не ожидаете, и я не предпочитаю запускать запрос LIKE через большую базу данных.

Вам нужно предоставить немного больше информации о том, как вы планируете использовать эти данные. Например, такие поля, как город, штат, страна, могут быть либо текстом в одной таблице, либо кодами, которые связаны с отдельной таблицей с помощью внешнего ключа.

Проще всего было бы

Address_Line_01 (обязательно, не пустой) Address_Line_02 Address_Line_03 Ориентир Город (Обязательно) Pin-Код (Обязательно) Province_District Состояние (Обязательно) Страна (Обязательно)

Все вышеперечисленное может быть текстом / Юникодом с соответствующей длиной поля.

Номера телефонов, если это применимо.