Есть ли преимущество в том, чтобы хранить данные об адресах отдельно, а не просто в виде строки?

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

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

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

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

Кроме того, в отношении поиска «Где StreetAddress Like«% whatever%»». Это все хорошо, если вы выполняете быстрый поиск для собственной выгоды, но когда вы пытаетесь автоматизировать части вашей системы, которые полагаются на адресные данные или даже пытаетесь удалить дубликаты, предоставьте пользователям автоматические предложения и т. д. и т. д., производительность снижается до такой степени, что она становится непригодной для использования по мере увеличения размера таблицы адресов.

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

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

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

SE 28-12-17-W5

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

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

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

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

Одна вещь, которую вы часто обнаружите, по крайней мере, в «Нефти и газе» (отсюда и основная часть моего опыта), это то, что рабочие часто ссылаются только на первые две части LSD, т. е. 28 из 12 или 43 из 16. Остальная часть LSD подразумевается местонахождением адреса, т. е. Гранд-Прери, Фокс-Крик, Вулф-Лейк и т. д.

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

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-Certified проверка ваших адресов. Вы можете связаться со мной лично с любыми вопросами, которые у вас есть.