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

Question

В настоящее время мы храним наши адресные данные так:

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 в БД).

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

SE 28-12-17-W5

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

Например, в Соединенных Штатах "линия доставки" улицы: PO Box 12345.

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

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

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

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

Answer 5

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

Answer 6

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

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