Які проблеми вирішуються шляхом поділу адрес вулиць на окремі стовпці?

У нас є команда, яка розробляє таблиці та відносини для розробників програмного забезпечення. У нашій організації вони досить суворо ставляться до забезпечення нормалізації 3NF - що, якщо чесно, я згоден з огляду на розмір нашої організації та те, як потреби чи клієнти змінюються з часом. Є лише одна сфера, яка мені не зрозуміла щодо причин їх дизайнерського рішення: адреси.

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

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

Це розділиться в базі даних так:

• Номер вулиці: 485
• Вулична частка: 1/2
• Напрямок вулиці: N (північ)
• Назва вулиці: Smith
• Тип вулиці: ST (Вулиця)
• Вулиця післянаправлення: SW (південний захід)
• Місто: Чикаго
• Штат: IL (Іллінойс)
• Поштовий індекс: 11111
• Код поштового індексу: 2222
• Країна (передбачається, що США)
• Увага: Джейн До
• Поштова скринька: NULL
• Тип житла: APT (Квартира)
• Номер житла: 300В

І ще було б кілька інших стовпців, пов’язаних із сільськими маршрутами та контрактними маршрутами. Крім того, наш конкретний додаток, ймовірно, має в ньому кілька міжнародних адрес. Моделери даних сказали, що вони додадуть стовпці, специфічні для міжнародних адрес, які будуть звичайними полями рядка 1, рядка 2.

Спочатку я подумав, що це БУДЬ за бортом. Дослідження в Інтернеті неодноразово стосується використання адресних рядків 1, 2, 3 та, можливо, 4, а потім розділення міста, регіону та поштового індексу. У нас є один випадок використання для нашої нової програми, коли ця деталізація є вигідною. Ми повинні підтвердити, що користувач не створює дубліката бізнесу, і перевірка адреси є однією з перевірок. Ми можемо змусити його працювати з адресними рядками 1 і 2, але це буде складніше.

Що стосується нашого конкретного додатка, нам потрібно зберігати кілька типів адрес для підприємств та людей (фізичні, поштові відправлення, доставка тощо). Ми могли б потрібно створити для друку листів, але ця вимога не обговорюється до цих пір.

Ще деякі додатки, які повинні підтримувати наші організації:

• Аудит (з повними таблицями історії)
• Друк поштових етикеток
• Формування друкованих форм
• Звітність (для національних та регіональних урядів)

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

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

Для того, щоб я краще зрозумів їхнє дизайнерське рішення та продав нашого клієнта за ідеєю ...

Які проблеми вирішуються шляхом поділу адреси вулиці на окремі стовпці?

Бонусні бали для кожного, хто реалізував подібну систему, тому що у них виникли проблеми.

До проблем, які можна вирішити розщепленням, належать

Перевірка Будь-яку частину імені можна порівняти з основним списком. Ті, що не відповідають, можуть бути відхилені. Поштовий індекс / поштовий індекс - очевидний приклад. Вони видаються та зберігаються незалежним органом. Єдиними дійсними є ті, які видає цей орган.

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

Аналіз Може бути корисним дізнатися, куди йдуть ваші замовлення, географічно ієрархічно. Це може призвести до збутових ініціатив, розробки продукції чи виплат комісійних тощо.

Копіювання коду Маючи всі програми в організації прийняти однакову модель даних (модель найскладнішого споживача), єдину кодову базу можна прийняти на всій території підприємства та підтримувати послідовно. Нескінченно продубльованого роздвоєння волосся можна уникнути або принаймні делегувати пропелери. Адреси, проведені в різних частинах організації, можна постійно оновлювати. Обслуговування та задоволення клієнтів можна збільшити. Зусилля з розробки можуть зосереджуватися на унікальних, високоцінних частинах системи.

Юридичні питання Закони та податки залежать від юрисдикції. Захоплюючи окремі значення адресних адрес окремо, простіше перехресне посилання даних транзакцій на вимоги відповідності.

Дублювання Легко підробляти адреси, що зберігаються у вигляді тексту, переміщуючи один елемент у наступний рядок або переробляючи деякі частини. Повністю проаналізовані адреси простіше порівняти. Це може бути простою проблемою якості даних, або може мати відповідність або кредитні наслідки, якщо, скажімо, кілька компаній-оболонок роблять великі замовлення на одну і ту ж адресу доставки, або кредитну карту використовують для доставки до багатьох розпорошених місць за короткий період.

Форматування частин, що проводяться окремо, можна комбінувати будь-яким способом, який відповідає поточній потребі. Якщо, скажімо, довгі тонкі етикетки для друку стали дешевими, ви можете переформатувати їх для використання.

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

Нарешті, я не відкидав би людський фактор. Модель даних виробляється модельєрами даних. Це те, що вони роблять. Це їх професія. Вони не збираються говорити вам просто скинути це в BLOB, чи не так?

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

Кожен населений пункт може мати свої примхи, і це тільки в США. Киньтесь в інші країни, і речі дуже швидко не піддаються управлінню для будь-якого підходу, який хоче проаналізувати кожну адресу. Лише два приклади:

В Іспанії номер вулиці завжди походить після назви вулиці та кома, і багато адрес містять порядковий номер підлоги, наприклад 1 ° або 3ª, а також абревіатури для "ліворуч" ("Вида", що означає ліву двері після ви піднімаєтесь сходами), "правильно" ("Дча") або інші можливості. Тепер помножте цю химерність на кількість різних країн та районів з різними історичними звичаями для адрес ... (Японія? Сільська Англія? Корея? Китай?)

У Портленді, АБО, є осі НС та СЗ, які ділять місто на квадрати NW, NE, SW та SE (а також N "квадрант", але я відступаю). НС вулиці пронумеровані по черзі на схід і захід від цієї осі, а адреси на вулицях EW продиктовані номером вулиці NS, що є "сотню блоку" номера (тобто будинок на вулиці EW між 11-м та 12-м проспектами мав би номер як 1123). Досить стандартний матеріал для адрес США.

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

Коли сітка була налаштована, вісь НС визначалася річкою Вілламет. Все на схід від річки було північно чи південно-східно, і на захід від річки північний чи північний. Коли місто росло на південь, вони зіткнулися з незручним фактом, що річка схиляється на Схід, тому проектуючи вісь Південь, у вас є ця проблемна зона, що на «західній» стороні річки, але на схід від осі. Рішення полягало в тому, щоб додати нульовий нуль, фактично знак мінус , при цьому числа збільшуються до Сходу від лінії осі.

Якби я був ти, я би відмовився від розробки досконалої системи. Ви не зможете охопити всі можливості, і нові будуть створюватися, коли людство проштовхується в раніше нерозвинену землю.

Щодо американських адрес, подивіться, що USPS вже зробив у стандартизації адрес, і не забудьте зробити house_numberколонку a varchar. Поки ви на це з'ясувати , як ви збираєтеся розібрати 1634 EN Fort Lane ін .

В іншому світі я, мабуть, спробую абстрагувати додаткові поля, щоб покрити 80-90% того, що, можливо, з'явиться, і надати набір неінтерпретованих полів, які можуть обробляти все інше, коли це необхідно. Тобто, якщо ваш аналізатор не вдається обробити адресу, збережіть його нерозбірливою і позначеною як такою. Якщо вам вдасться розібрати адресу, переконайтеся, що ви пам’ятаєте порядок, в якому ви знайшли різні поля, щоб ви могли зібрати її в щось доставлене.

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

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

Як і всі питання дизайну, існує надзвичайно кваліфікований "це залежить". Це залежить від вашої історії даних - як збираються дані, як вони використовуються, як оновлюються тощо. Усі мої коментарі слід сприймати як точки обговорення, а не як відповіді як відповіді.

Це звучить як * ви могли б отримати більше користі від використання послуги перевірки адреси, ніж намагатися створити її для себе. Хоча вони коштують дорого, багато таких послуг мають значні знижки на розсилку.

Звичайно, тут є компроміс для певних сюжетів даних. Ви можете зберегти розібрані фрагменти адреси та створити обчислений стовпець (набір стовпців, ймовірно) для комбінованої адреси. Це відповідь на реалізацію з усіма нормальними застереженнями.

Я реалізував розібраний дизайн адреси. Нам це абсолютно потрібно для якості даних ТА потреб у обробці даних. Але це був бізнес, який мав фізичні адреси, поштові адреси, віртуальні адреси тощо.

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

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

Я настійно рекомендую писати та вести ведення блогів Грем Рахінг. Він фахівець у галузі даних щодо адрес усіх видів та пов'язаних з ними компромісів.

_{* Все, що я тут сказав, - це грубе узагальнення. Стільки питань, які мені доведеться допомогти прийти до дизайнерського рішення, що може зайняти кілька годин спілкування в чаті. Ймовірно, деякі фотографії та деякі дані профілювання теж. І тоді багато справді химерних історій даних про адреси.}

Цілком залишаючи осторонь величезну проблему правильного розбору непередбачуваного гнучкості, яку люди пропонують, користь розбору полягає в тому, що він дає вам розміри для групування та сортування. Поштовий індекс, наприклад. Однак від розбору певного виміру немає виплат , поки вам не потрібно згрупувати чи сортувати цей параметр.

Що це за адреса? Ви можете зробити хороший випадок, що це ідентифікатор місця, але ви можете зробити так само непоганий випадок, що це інструкції з доставки - "По вулиці від цементного заводу". В Австралії люди вважають, що поштові індекси - це ідентифікатори місцеположення, але це не так, вони коди маршрутизації - інструкції з доставки. 4702 - Рокгемптонський поштовий центр, основний вузол розподілу, що обслуговує регіон, що тягнеться від моря до Смарагдового, гірського містечка, що знаходиться на відстані 300 км.

Якщо ви хочете визначити місцеположення, тоді Bing та Google можуть геокодувати безпосередньо з нерозділеного рядка в GPS-координати, які можна зберігати в невеликій, простої таблиці разом з нерозділеною рядком. Вони використовують єдиний загальний підхід з будь-якими шансами на стабільно хороші результати: ранжирують зважене часткове узгодження з колосальною базою даних підтверджених результатів.

Якщо ви хочете отримати інструкції з доставки, вам все-таки рекомендується зберігати нерозділену рядок, оскільки вона може містити що- небудь .

Зауважте, що в обох випадках я рекомендував зберігати непарний рядок. Це тому

• це корисно саме по собі
• одного дня ви зрозумієте, як розібратися
• через пару днів ви зрозумієте, як правильно її розібрати
• це ніколи не закінчується

Адже, ймовірно, адреса - це завжди інструкції про доставку, що містять принаймні один ідентифікатор місцезнаходження. Лист, адресований "123 Main Street, Emerald 4702" кодує три місця: RMC у північній частині Рокгемптона, Emerald та адресу вулиці. Поштове відділення Rockhampton просто надішле його в RMC. RMC надішле його на поштове відділення Emerald, а поштове відділення Emerald, сподіваємось, знає, де знайти 123 Main Street.

Я впровадив таку систему, як раніше, хоча в Нідерландах. Річ у тім, що така інформація може змінюватися більш, ніж ви думаєте. Вулиці перейменовані, міста об’єднані тощо. Приємно мати можливість оновлювати таку інформацію, не аналізуючи адреси як єдиний рядок.

Відокремлення поштового індексу / поштового індексу, назви будівлі, назви дороги може мати сенс. Але тоді, коли ви починаєте додавати "місто", "область" і т. Д., Це стає сумнівним, порівняно з просто рядком1, рядком2 і т.д. Чи слід вказувати назву "село" у міському полі, чи воно йде в рядку під назвою дороги, а місцеве місто розміщується на міських полях? (Деякі люди ображаються, якщо ви телефонуєте там, де вони живуть селом, а не містом, інші люди, які живуть у тому самому місці, ображаються, якщо ви називаєте це місто замість села!)

Тому намагатися робити що-небудь фантазійне не краще, ніж система перевірки адреси, яку ви використовуєте. Але стає ще гірше. У Великобританії ВСІ адреси повинні мати поштовий індекс, але все ж поштовий індекс не присвоюється до моменту побудови будинку …… Отже, система повинна дозволяти порушувати кожне правило щодо адреси!

Окрім проблем, про які вже йшлося в інших відповідях, у деяких мовах - зокрема, германській - назви вулиць, як правило, є складними. Наприклад, у багатьох німецьких містах / містах зазвичай є "Bahnhofstrasse" - вулиця, що йде до залізничної станції ("Bahnhof" означає залізничний / залізничний вокзал, "Strasse" означає вулицю). Звичайно, ви могли б відокремити ці два компоненти, але тепер, якщо ви хочете скласти їх разом (програмно), ви потрапляєте у питання відхилення.

Або в мовах "романтика" або латиніату ви часто маєте назви вулиць форми "Rue de la Pais" або "Boulevard des Champs-Élysées". Тепер у вас у суміші є прийменник ("де") та певна стаття ("ле" чи "ля"), і вони можуть поєднуватися. Чи вони представляють частину типу вулиці чи назви вулиці? (Напевно, вам потрібно буде десь зберігати їх, інакше ви знову потрапите в скорочення.)

Я колись моделював щось подібне. Але це було дуже невелике застосування для офісу з обслуговування житлової нерухомості середнього університету (у США). Я зробив адреси дуже чіткими з наступних причин:

• У цьому районі були вулиці з такою ж назвою, але іншого типу вулиць (наприклад, «Вудс Авеню» проти «Вудс Корт»).
• Користувачі хотіли мати можливість оптимізувати роботи з обслуговування, наприклад, якщо на одному блоці було два або більше запитів на обслуговування, з якими можна було б оброблятись одночасно.
• Користувачі хотіли мати можливість співвідносити проблеми між різними одиницями (квартирами) в одній будівлі - наприклад, якщо більше однієї квартири повідомили про холодну температуру або недостатньо гарячу воду.

... та інших причин, яких я вже не пам’ятаю. (Це було наприкінці 1980-х.)

І знову, це мало сенс лише тому, що було вирішено досить малу кількість адрес (та правил форматування адреси). Я не вірю, що цей підхід мав би масштаб, навіть якщо він обмежений адресами США, з причин, уже вказаних в інших відповідях.