Какой универсальный способ сохранить географический адрес / местоположение в базе данных? [закрыто]

Какой правильный формат географического адреса / местоположения подходит для любого адреса на Земле? На данный момент у меня есть:

• страна
• город
• улица
• количество
• текстовые данные (для простоты)
• застежка-молния
• Lat / LNG

Но я верю, что могу это улучшить: это может быть штат / регион страны или что-то вроде области. Или нет области / региона / штата, скажем, в Сингапуре или Гонконге.

Там может быть не улица, а дорога, бульвар или что-то еще. Номер здания может быть составным. Там может быть пол. Номер комнаты. Так далее....

Google разработал библиотеку, которая помогает проверять почтовые адреса для каждой страны в мире, которую вы можете использовать для разработки схемы для хранения этих данных.

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

Универсальный способ сохранить географический адрес / местоположение в базе данных:

[Address] nvarchar(max) not null

Это требует наименьшего количества программного кода (и, следовательно, сокращает расходы на обслуживание) и полностью совместимо с любым адресом. Однако у него есть три большие проблемы:

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

• Данные, хранящиеся таким образом, делают невозможным их обработку в целях бизнес-аналитики и анализа данных. Например, сколько пользователей из Индии? Нет простого способа узнать, так как эти адреса не будут нормализованы.

• Пользователи могут по ошибке ввести неполный или явно неправильный адрес.

Чтобы смягчить первую проблему, ограничьте поле тем, что вы считаете разумным. Лично я начну с 1000 символов, а затем уменьшу ее в зависимости от длины адресов, введенных первыми пользователями, когда вы получите достаточно большой набор данных.

Чтобы смягчить другие две проблемы, вы можете использовать сторонний API, который анализирует адреса и предоставляет вам данные, содержащие страну, город, почтовый индекс и т. Д. Если возможно, API должен иметь возможность отображать адрес на карту, возвращаемую пользователю, чтобы снизить риск для пользователя ввести неполный или неправильный адрес: большинство пользователей знают, где они живут, и, видя другую позицию на карте, сразу же даст им подсказку, что они должны проверить свои данные.

Обратите внимание, что какой бы API вы ни использовали, он не будет идеальным. Он найдет большинство адресов, но не все из них. Это означает, что если API сообщает, что адрес не существует, но пользователь настаивает на том, что он существует, вам следует априори доверять пользователю, даже если он ошибается.

Это также означает, что вы все равно должны хранить исходные данные пользователя, параллельно с результатами API. Это означает, что схема становится:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

Там нет ни одного.

Каждая страна имеет разные форматы адресов. Если вам повезет, и у них есть формат вообще!

Очевидно, что широта / долгота даст вам точку на земном шаре, но это не очень полезно для идентификации отдельных домов. Для примера рассмотрим башенный блок.

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

Например, в Великобритании есть такие вещи, как «двойной зависимый населенный пункт», но никто не узнает, что это значит, если вы спросите их.

Единственным универсальным форматом является наличие одного текстового поля, которое может содержать несколько строк текста. Это позволит любой возможный адрес на земле.

Я занимаюсь разработкой программных решений для использования во многих странах. Мы решаем эту проблему, сначала начав с более крупного объекта, т. Е. Затем у страны есть поля до наименее общего или наименьшего. Это хорошо работает для всех стран, с которыми мы экспериментировали до сих пор. У нас также есть интеллектуальная система предотвращения дублирования и объединение для тех, кто каким-то образом попал в систему, поскольку пользователи очень «креативны». В разделе администратора у нас есть порядок полей адреса для каждой страны. т. е. в Японии сначала указан почтовый индекс, а в конце - Великобритания / США.

В общем, мы используем:

• Страна
• Post / Zip-код
• Штат / Провинция / / префектура округа
• Город / Город / деревня
• Улица / Дорога / Block
• Название здания / Номер
• Конкретная / Пользовательская информация

После ввода и сохранения можно отобразить сопряженную версию, оставляя поля не обязательными.

Как я уже сказал, это работает для всех тех стран, в которых у нас есть программное обеспечение, и является результатом его разработки с 1989 года.

Надеюсь, что это поможет или, по крайней мере, даст другое понимание.

Как уже говорилось, наиболее универсальным (но непрактичным для проверки и, возможно, наименее полезным) является одно большое поле Юникода.

Вы можете отделить страну от остальной части адреса и сохранить ее как код страны ISO. Это нормализовало бы страну и предложило бы некоторую полезность в проверке оставшейся части адреса.

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

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

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

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

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

Как вы говорите, любой адрес на земле есть только широта или ...

https://what3words.com

То, что 3 слова, - это алгоритм (поэтому он не является базой данных, поэтому может быть встроен во что угодно), который может определять участок размером 3х3 метра в любой точке Земли.

Тонга и несколько других штатов приняли ее в качестве своей системы почтовых индексов, хотя она не заменит ее в качестве наложения, она довольно крутая, очень хорошо сложенная и продуманная.