Есть ли польза от хранения данных об адресах отдельно, а не просто в виде строки?

https://stackoverflow.com/questions/1626432

06-07-2019
|

Вопрос

В настоящее время мы храним наши адресные данные следующим образом:

string suiteNumber (ie. unit number)
string streetNumber (building number)
string streetName
string streetDirection (N/NW/S/etc.)
string streetType    (rd/st/ave/etc.)
// ... etc. (postal code/city/province/state/country

Но я столкнулся с (насколько я могу судить) проблемой анализа первых 5 частей адреса при работе с адресами и их импорте.

Я думаю, что все это было бы значительно проще, если бы адрес был просто строкой (varchar в базе данных).

Мне привели два аргумента в пользу того, почему нам следует оставить все как есть:1.Поиск становится проще, если вы можете искать ТОЛЬКО по названию улицы, номеру улицы и т. д.но я думаю, что сценарий sql типа SELECT x FROM Address WHERE streetAddress LIKE "%ВХОД%";Конечно, это не так быстро, но это сработает (и набор данных для этого поиска только по клиентам невероятно меньше, чем набор всех адресов, которые мы сохранили).

В настоящее время у нас есть система, которая помечает квартиры: если вы обнаружите, что 1 человек по адресу А является квартирой, мы помечаем его, и она будет искать всех остальных людей по этому номеру улицы/названию улицы и также отмечать их (это иногда важная деловая необходимость)

Я уже храню их все как строки из-за множества исключений в адресах.

Итак, я спрашиваю, есть ли особые причины для необходимости/желания хранить части адреса отдельно?

Решение

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

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

Вот мой пост в блоге:

http://www.endswithsaurus.com/2009 /07/lesson-in-address-storage.html

Кроме того, в связи с поиском " Где StreetAddress Нравится '% what%' " ;. Это хорошо, если вы выполняете быстрый поиск своей выгоды, но когда вы пытаетесь автоматизировать те части вашей системы, которые используют адресные данные или даже удаляют дубликаты, предоставьте пользователям автоматическое предложение и т. Д. и т. д. производительность снижается до такой степени, что она становится непригодной для использования при увеличении таблицы адресов.

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

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

Юридические подразделения (ЛСД) используются в основном в Oil & amp; Газовые и другие сырьевые отрасли промышленности в Альберте, Саскачеване и Манитобе (хотя они также находятся в некоторых частях Британской Колумбии, они не используются так широко). Все они имеют одинаковый формат: Секция, Городок, Спектр, Меридиан. Например:

SE 28-12-17-W5

Это юго-восточный угол Раздела 28, Городок 12, Диапазон 17, к западу от 5-го Меридиана.

Вы можете просто использовать одно поле и анализировать его с помощью регулярных выражений или разбивать его на отдельные поля, содержащие разбивку LSD. Запуск регулярных выражений в SQL Server может быть проблемой, когда дело доходит до производительности. Я думаю, что это то же самое, что и адресные данные в целом, потому что каждый фрагмент данных является отдельным уникальным фрагментом данных, который они должны храниться в отдельных полях. Однако, учитывая, что подавляющее большинство этого типа адресных данных не используется широкой публикой вместо уличного адреса, я мог бы рекомендовать разработать нечто, что позволило бы отделить эту информацию от (но связаны с) вашими основными адресными данными. Однако, учитывая, что описание земли / LSD также является частью каждого канадского адреса, у меня может возникнуть желание сохранить его в моей основной таблице адресов в зависимости от целевой аудитории базы данных.

Вот пост о разрушении системы земельных ресурсов Альберты:

http://www1.agric.gov. ab.ca/%24department/deptdocs.nsf/all/agdex10302

Одна вещь, которую вы часто найдете в Oil & amp; По крайней мере, газ (из которого я получил основную часть моего опыта) состоит в том, что работники часто ссылаются только на первые две части ЛСД - т.е. 28 из 12 или 43 из 16. Остальная часть ЛСД подразумевается месторасположение адреса - например, Гранд-Прери, Фокс-Крик, Вулф-Лейк и т. д.

Другие советы

Раньше я думал, что это хорошая идея, пока мои приложения не были развернуты и не поступил постоянный поток запросов на изменения. В то время я жил в Онтарио, Канада, и думал, что знаю, как выглядит стандартный адрес. До тех пор, пока у какого-то клиента не было адреса, который объединял бы P.O. Коробка и адрес улицы в одну. Затем клиенты Alberta начали приходить со своими структурированными кодами, упомянутыми в другом ответе. Затем Британская Колумбия обращается к тем адресам, где не было ни улицы, ни номера улицы, только место и отсек, а также сельский маршрут. C4, S16 RR7 Mountainville. А затем с американскими поставщиками правила почтового индекса вышли в окно. А потом в базе данных появился случайный британский клиент, и все, что вы думали, что знали об адресах, вылетало в окно. Название здания без номера улицы, двух названий улиц, двух названий городов в одном адресе!

Bright House,
Waverly Crescent off Oxford Road,
Seething-under-Norton, Banbury,
Oxfordshire
OB7 3VT
United Kingdom

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

В случае с этим адресом в Ситинг-андер-Нортоне, вероятно, есть еще один Вейверли Полумесяц, поэтому и название второй улицы. А Зитинг-под-Нортон был деревней, которая давно вошла в состав города Банбери, поэтому оба имени указаны в адресе. В британских адресах вы часто получаете муниципалитеты, которые не существуют. Они считаются почтовыми городами в том смысле, что они существуют только внутри почтовой системы. Обычно есть историческая основа для названия. Многие лондонские адреса похожи на то, что люди пишут Лондон один раз, а Лейтон или Саут-Руислип или Хиллингдон - в другой раз. Все письма доставляются быстро.

Поэтому, если функция вашего программного обеспечения не препятствует вводу внешних адресов в систему, не делайте этого!

Кстати, вы упомянули, что идентифицировали всех людей на одной улице по названию улицы. Вы проверили Денвер, штат Колорадо, где есть названия улиц, которые заканчиваются и набирают снова, в миле дальше. Однажды я заблудился в Литтлтоне (пригород Денвера), пытаясь найти определенный адрес, и мне сказали, что мне нужна еще одна такая-то улица, которая была в другом месте. Затем есть британская практика использования двух или более названий для каждой дороги. Например, будет Гомертон-роуд, которая затем будет называться Марш-Хилл, затем Гомертон-Хай-стрит, затем Урсвик-роуд, а затем Лоуэр-Клэптон-роуд, все в пределах километра или двух. Чаще всего в деревне Вик будет Нортон-роуд. Если вы последуете ей, то через одну-две мили вы заметите, что вы сейчас находитесь на Вик-роуд, въезжая в деревню Нортон.

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

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

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

В Европе уличным адресом обычно является имя плюс «номер» (где число может быть чем-то вроде «3a»). Я видел базы данных, которые хранят их отдельно по одной причине: вы можете искать названия улиц в официальной базе данных, чтобы проверить их (например, для защиты от опечаток). Поэтому для этого варианта использования имеет смысл хранить проверяемые и непроверяемые части в разных столбцах.

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

Выгодно, если вы придерживаетесь ориентированного на цель подхода для моделирования всего своего домена. Ваш вопрос напоминает мне это название блога Март - это не число в качестве ответа. Что-то аналогичное можно сказать об улицах и адресах («улица - это не строка»). SnOrfus указывает на действительную проблему в своем комментарии.

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

Например, в Соединенных Штатах это «линия доставки» улицы:Почтовый ящик 12345.

В этом случае «Почтовый ящик» на самом деле является названием улицы, а 12345 — основным номером.Обычное «форматирование» и общепринятое мнение предполагают, что в адресе первым должен быть указан основной номер, как в «123 Main Street».

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

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

Для полного раскрытия информации: я основатель SmartyStreets.Мы предлагаем базирующиеся в США проверка адреса услуги, которые включают в себя Сертифицированная CASS проверка ваших адресов.Вы можете связаться со мной лично по любым вопросам.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow