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

У нас есть команда, которая разрабатывает таблицы и отношения для разработчиков программного обеспечения. В нашей организации они достаточно строги в отношении обеспечения нормализации 3NF - что, честно говоря, я согласен с учетом размера нашей организации и того, как меняются потребности или наши клиенты с течением времени. Есть только одна область, в которой мне не совсем понятны причины их дизайнерского решения: адреса.

Хотя в основном это касается адресов в Соединенных Штатах, я думаю, что это может относиться к любой стране, которая делает это. Каждый фрагмент адреса получает свой собственный столбец в таблице адресов. Например, возьмите этот мрачный американский адрес:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

Это будет разделено на базу данных следующим образом:

• Улица номер: 485
• Фракция улицы: 1/2
• Улица направленная: N (север)
• Название улицы: Смит
• Тип улицы: ST (Улица)
• Улица пост-направленная: юго-запад (юго-запад)
• Город: Чикаго
• Штат: Иллинойс (Иллинойс)
• Почтовый индекс: 11111
• Почтовый индекс: 2222
• Страна (предполагается, что США)
• Внимание: Джейн Доу
• PO Box: NULL
• Тип жилища: APT (Квартира)
• Номер жилища: 300B

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

Сначала я думал, что это был путь за бортом. Исследования в Интернете неоднократно относятся к использованию адресной строки 1, 2, 3 и, возможно, 4, а затем к разделению города, региона и почтового индекса. У нас есть один вариант использования для нашего нового приложения, где такая гранулярность выгодна. Мы должны подтвердить, что пользователь не создает дублирующую компанию, и проверка адреса является одной из проверок. Мы можем заставить его работать с адресной строкой 1 и 2, но это будет сложнее.

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

Некоторые другие вещи, которые приложения в нашей организации должны поддерживать:

• Аудит (с полными таблицами истории)
• Печать почтовых этикеток
• Генерация печатных форм
• Отчетность (для национальных и региональных органов власти)

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

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

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

Какие проблемы решаются путем разделения адреса улицы на отдельные столбцы?

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

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

Валидация Любую часть имени можно сравнить с основным списком. Те, которые не совпадают, могут быть отклонены. Почтовый индекс / почтовый индекс является очевидным примером. Они выпущены и поддерживаются независимым органом. Единственными действительными являются те, которые выпущены этим органом.

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

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

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

Правовые вопросы Законы и налоги зависят от юрисдикции. Собирая подробные значения адресов по отдельности, проще связать транзакционные данные с требованиями соответствия.

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

Форматирование Части, хранящиеся отдельно, можно комбинировать любым способом, который соответствует текущей потребности. Если, скажем, длинные тонкие этикетки становятся дешевыми, вы можете переформатировать их.

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

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

Я потратил 7 лет на разработку программного обеспечения для издательской компании, и одной из самых сложных проблем, с которыми мы когда-либо сталкивались, был анализ уличных адресов в списках подписчиков. Полезно разделять адреса на отдельные поля, но вы никогда не сможете НИКОГДА проектировать каждую возможную патологическую аберрацию форматов адресов и компонентов, которые человеческий мозг может придумать.

У каждого населенного пункта могут быть свои причуды, и это только в США. Бросить в другие страны и вещи становятся неуправляемыми очень быстро для любого подхода, который хочет разобрать каждый адрес. Всего два примера:

В Испании номер улицы всегда идет после названия улицы и запятой, и многие адреса содержат порядковый номер этажа, например, 1 ° или 3ª, а также сокращения для «left» («Izda» означает «левая дверь после»). Вы поднимаетесь по лестнице), «правильно» («Дча») или другие возможности. Теперь умножьте эту причудливость на количество разных стран и областей с разными историческими обычаями для адресов ... (Япония? Сельская Англия? Корея? Китай?)

В Портленде, штат Орегон, есть оси NS и EW, которые делят город на квадранты NW, NE, SW и SE (а также N "квадрант", но я отвлекся). Улицы NS нумеруются по порядку с востока на восток и запад от этой оси, а адреса на улицах EW определяются числом улиц NS, равным «сотенному блоку» числа (т. Е. Дом на улице EW между 11-й и 12-й улицами будет иметь номер как 1123). Довольно стандартный материал для адресов в США.

Каждый так часто вы бежите в адрес Портленд , как 0205 SW Nebraska St . Ведущий ноль? WTF? Там идет моя integerколонка для дома "номер".

Когда сетка была настроена, ось NS была определена рекой Willamette. Все к востоку от реки было северо-восточнее или юго-восточнее, а западнее реки северо-западнее или юго-западнее. По мере того как город рос на юг, они сталкивались с неудобным фактом, что река изгибается на восток, поэтому, проецируя ось на юг, вы получаете эту проблемную область, которая находится на «западной» стороне реки, но к востоку от оси. Решение состояло в том, чтобы добавить начальный ноль, фактически знак минус , с увеличением числа на восток от линии оси.

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

Что касается адресов в США, взгляните на то, что USPS уже сделала в области стандартизации адресов, и не забудьте сделать house_numberстолбец a varchar. Пока вы на это выяснить , как вы собираетесь разобрать 1634 EN Fort Lane пр .

Для остального мира я, вероятно, попытался бы абстрагировать дополнительные поля, чтобы покрыть 80-90% того, что может появиться, и предоставить набор неинтерпретируемых полей, которые могут обрабатывать все остальное, когда это необходимо. Т.е. если вашему парсеру не удается обработать адрес, сохраните его без разбора и пометите как таковой. Если вам удастся проанализировать адрес, убедитесь, что вы помните порядок, в котором вы нашли различные поля, чтобы вы могли собрать его во что-то доставляемое.

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

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

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

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

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

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

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

Наконец, вам не нужны международные бизнес-операции для поддержки международных данных. Даже американские компании должны поддерживать международные адреса. Это огромная ошибка в данных, чтобы предположить, что у вас этого никогда не будет Клиенты перемещаются, поставщики меняют свои штаб-квартиры, контактные данные поставщиков могут быть международными, даже если у них есть штаб-квартира в США. Даже если ваши нынешние системы допустили эту ошибку, вы не хотите продолжать эту.

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

_{* Все, что я сказал здесь, это грубое обобщение. Есть так много вопросов, которые я должен помочь прийти к дизайнерскому решению, что это может занять несколько часов в чате. Скорее всего, некоторые изображения и некоторые данные профилирования тоже. А потом много действительно причудливых историй с данными об адресах.}

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

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

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

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

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

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

Возможно, адрес - это всегда инструкция по доставке, содержащая хотя бы один идентификатор местоположения. Письмо, адресованное «123 Main st, Emerald 4702», кодирует три местоположения: RMC в северной части Рокхемптона, Emerald и адрес улицы. Почтовое отделение Rockhampton просто отправит его в RMC. RMC отправит его в почтовое отделение Emerald, и, надеюсь, Emerald Post знает, где найти главную улицу 123.

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

Разделение почтового индекса / почтового индекса, названия здания, названия дороги может иметь смысл. Но потом, когда вы начинаете добавлять «город», «район» и т. Д., Это становится сомнительным, по сравнению с просто строкой 1, строкой 2 и т. Д. Проблема в том, что даже я и моя жена не можем договориться о названии города, в котором мы живем! Название «деревня» должно быть введено в поле города или оно должно быть в строке ниже названия дороги, а местный город - в полях города? (Некоторые люди обижаются, если вы называете их городом, а не деревней, а другие люди, живущие в том же месте, обижаются, если вы называете это городом, а не деревней!)

Поэтому попытка сделать что-то необычное не лучше, чем система проверки адресов, которую вы используете. Но это становится еще хуже. В Великобритании ВСЕ адреса должны иметь почтовый индекс, но почтовый индекс не назначается до тех пор, пока не будет построен дом …… Таким образом, система должна разрешить нарушение всех правил об адресе!

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

Или, в «романском» или латинском языках, у вас часто есть названия улиц в форме «Rue de la Pais» или «Boulevard des Champs-Élysées». Теперь у вас есть предлог («де») и определенная статья («ле» или «ля») в миксе - и они могут быть объединены. Они представляют часть типа улицы или названия улицы? (Вам, вероятно, нужно где-то их хранить, иначе вы снова склоняетесь.)

Я однажды сделал что-то подобное. Но это было очень небольшое приложение для офиса по обслуживанию жилой недвижимости среднего университета (в США). Я сделал адреса очень детальными по следующим причинам:

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

... и другие причины, которые я больше не помню. (Это было в конце 1980-х годов.)

И опять же, это имело смысл только потому, что было достаточно небольшое количество адресов (и правил форматирования адресов) для работы. Я не верю, что этот подход будет масштабироваться, даже если он ограничен адресами США, по причинам, уже указанным в других ответах.