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

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

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

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

Для более широкого международного использования одна схема, которую следует рассмотреть, - это та, которая используется Drupal Address Field . Он основан на стандарте 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Где "компромисс" при хранении ZIP в виде ЧИСЛА или VARCHAR? Это просто выбор - это не компромисс, если нет преимуществ для обоих, и вам нужно отказаться от некоторых преимуществ, чтобы получить другие.

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

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

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

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

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

На основе ответов базы данных

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Я бы просто поместил все поля вместе в большое поле NVARCHAR (1000) с элементом textarea, чтобы пользователь мог ввести значение (если вы не хотите выполнять анализ, например, почтовых индексов). Все эти вводы в адресной строке 1, адресной строке 2 и т. Д. Просто раздражают, если у вас есть адрес, который не соответствует этому формату (и, как вы знаете, есть другие страны, кроме США).