Лучшие практики для хранения почтовых адресов в базе данных (RDBMS)?

Question

Есть ли хорошие рекомендации по передовым методам хранения почтовых адресов в СУБД? Кажется, есть много компромиссов, которые можно сделать, и много плюсов и минусов для каждого из них, чтобы оценить - конечно, это было сделано снова и снова? Может, кто-то хотя бы написал, где-то извлек уроки?

Примерами компромиссов, о которых я говорю, является сохранение почтового индекса в виде целого числа по сравнению с полем char, если номер дома должен храниться как отдельное поле или часть адресной строки 1, если номера suite / apartment / etc будут нормализованы или просто хранится в виде фрагмента текста в адресной строке 2, как вы обрабатываете zip + 4 (отдельные поля или одно большое поле, целое число против текста)? и т.д.

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

Answer 1

Для более международного использования одной схемой, которую следует рассмотреть, является схема, используемая Адресное поле Drupal . Он основан на стандарте xNAL и, похоже, охватывает большинство международных случаев. Немного покопавшись в этом модуле, вы обнаружите несколько замечательных жемчужин для интерпретации и проверки адресов на международном уровне. Он также имеет хороший набор административных областей (провинция, штат, область и т. Д.) С кодами ISO.

Вот суть схемы, скопированной со страницы модуля:

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

Уроки, которые я выучил:

• Не храните ничего в цифровой форме.
• Храните страну и административный район как коды ISO, где это возможно.
• Если вы не знаете, будьте осторожны с полями. Некоторые страны могут не использовать поля, которые вы считаете само собой разумеющимися, даже такие базовые вещи, как locality & thoroughfare.

Answer 2

Как «международный» пользователь, нет ничего более разочаровывающего, чем работа с веб-сайтом, ориентированным только на адреса в американском формате. Сначала это немного грубо, но становится серьезной проблемой, когда проверка также чрезмерно усердна.

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

Я бы посоветовал просто ~ 10 строк строки переменной длины вместе с отдельным полем для почтового индекса (и будьте осторожны, как вы описываете это, чтобы справиться с национальными особенностями). Пусть пользователь / клиент решит, как написать свои адреса.

Answer 3

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

Справочное руководство Фрэнка по почтовым адресам
Эффективная адресация для международной почты

Answer 4

Вы, безусловно, должны рассмотреть вопрос о сохранении номера дома как символьного поля, а не числа, из-за особых случаев, таких как «полуколичества», или моего текущего адреса, который похож на «129A» - но A не считается в качестве номера квартиры для служб доставки.

Answer 5

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

Я смутно припоминаю некоторые проблемы с норвежскими почтовыми кодами (я думаю), которые были всеми 4 позициями, кроме Осло, где было 18 или около того.

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

(В итоге мы зарегистрировали людей с адресом за границей в стране с ISO-кодом 'ZZ'.)

Answer 6

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

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

Стоимость дискового пространства будет намного дешевле, чем стоимость его исправления позже ... у кого-нибудь еще?

Answer 7

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

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

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

На мой взгляд, часто (что не означает всегда ) имеет смысл как для записи «изображения метки адреса» адреса, так и для отдельного анализа содержимого. Это позволяет бороться с различиями в размещении почтовых индексов, например, между разными странами. Конечно, вы можете написать анализатор и форматер, который обрабатывает эксцентриситеты разных стран (например, адреса в США имеют 2 или 3 строки; напротив, адреса в Великобритании могут иметь значительно больше; один адрес, на который я пишу периодически, имеет 9 строк). Но может быть проще, чтобы люди занимались анализом и форматированием и позволяли СУБД просто хранить данные.

Answer 8

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

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

Answer 9

Добавление к тому, что @ Джонатан Леффлер и @ Пол Фишер сказал

Если вы когда-либо предполагали, что почтовые адреса для Канады или Мексики будут добавлены к вашим требованиям, необходимо сохранить postal-code в виде строки. В Канаде есть буквенно-цифровые почтовые индексы, и я не помню, как выглядит Мексика с моей головы.

Answer 10

Это может быть излишним, но если вам нужно решение, которое будет работать с несколькими странами, и вам нужно программно обрабатывать части адреса:

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