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

108

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

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

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

Джон
источник
3
Сразу же почтовый индекс должен быть символьным полем, иначе некоторые почтовые индексы, начинающиеся с 0, будут неточными.
Менашех
1
Как правило, когда вам нужно выполнить математические вычисления с числом, оно должно быть целым. Если вы только отображаете его, это должен быть символ (телефон, почтовый индекс и т. Д.)
Зикато

Ответы:

37

Для более широкого международного использования одна схема, которую следует рассмотреть, - это та, которая используется 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.
Сэмм Купер
источник
1
Могу я спросить, для чего предназначена name_line? Я действительно не нашел объяснения в Drupal Docs или xNal Standard. Насколько я понимаю name_line предназначена для отправки реальных писем или посылок по почте. First_name / last_name нужен только если вы хотите , чтобы обратиться к клиенту напрямую, например , по электронной почте ( «Уважаемый господин <last_name>»). Или у него есть какая-то другая цель / польза?
luba
При доставке в (большие) коммерческие помещения для внутренней системы доставки почты часто необходимо имя (рассмотрим офисные здания с почтовыми залами)
Крис Браун
Поле адреса заменено адресом . Похоже, поля могут быть немного другими
Гэвин Хейнс,
24

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

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

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

Эндрю Феррье
источник
Как бы то ни было, это не для веб-сайта, но вопрос о международных адресах по-прежнему хорошо понимается.
Джон
47
Хотя я не согласен с этим сообщением и на самом деле я аплодирую вам за вашу позицию, мне пришлось проголосовать против вас, потому что я ненавижу этот факт как человек, который тратит большую часть своего времени на написание инструментов для очистки адресных данных хранения адресных данных в произвольном формате. Адреса могут быть отформатированы по-разному, но данные остаются в основном теми же. Отображается ли номер дома перед названием улицы или после него, в значительной степени не имеет значения для целей хранения - только для целей отображения.
BenAlabaster
20

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

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

Splattne
источник
17

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

Пол Фишер
источник
11

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

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

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

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


источник
8

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

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

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

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

Джонатан Леффлер
источник
7

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

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

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

Seanb
источник
7

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

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

Кен Джентл
источник
7

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

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************
Gaz_Edge
источник
Как вы храните почтовые ящики?
Jowen
просто добавьте еще один столбец PO_box. Если вам нужно сделать это ретроспективно, это означает, что ни один из предыдущих адресов не нуждался в почтовом ящике, поэтому его можно установить на нуль
Gaz_Edge
2

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

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


источник
Одним из компромиссов может быть размер базы данных. В mysql 5 строка mediumint занимает всего 3 байта на строку, а varchar (5) - вдвое больше. Я также думал, что числовой поиск быстрее, чем текстовый, но я не уверен в этом.
gpojd
4
следует использовать varchar. В почтовом индексе Канады используется буквенно-цифровая кодировка, которая не подходит для числа.
EvilTeach
1
Хотя я понимаю логику "прямой совместимости", лежащую в основе использования varchar в этом смысле, утверждение, что "zip as number бесполезны", слишком догматично. Если вы знаете, что собираетесь работать с почтовыми индексами только для США, имеет смысл хранить почтовые индексы как целые числа, точно так же, как при написании на строго типизированном языке, вы не определяете все как тип String ... Если вы знайте, что это будет число, почему бы не опереться на проверку типов в БД / языке программирования и назвать это как есть - целым числом?
риного
1
@rinogo Одним из аргументов в пользу использования varchar является то, что почтовые индексы не являются числовыми в математическом смысле; нет смысла делать на них сложение или вычитание; они просто закодированы с помощью ограниченного набора символов. stackoverflow.com/a/893489/48659
Стив Фолли,
1
@SteveFolly И в дальнейшей поддержке того, что почтовые индексы являются строками, ведущие символы имеют особое значение: en.wikipedia.org/wiki/ZIP_Code#Primary_state_prefixes Если кто-то собирается реализовать логику типа «какие символы крайнего левого значения в значении? ? " тогда это наверняка больше похоже на строку, чем на целое число.
Дэвид Олдридж
2

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

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

Шанму
источник
Я действительно думал об этом сам. В дополнение или, возможно, вместо таблицы, которая сопоставляет столбцы с подсказками в зависимости от страны, я думал о создании обновляемых представлений для каждого конкретного формата адреса. Еще не нажал на курок, но задумался.
Эндрю Стейтц
1

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

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

Тед Бигхэм
источник
-1

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

Эриккаллен
источник
3
Какая ужасная идея! В «Комментарии» недостаточно места, чтобы описать кошмар, который это вызывает. Лучше потратить немного больше времени на его правильное проектирование, чем потом пытаться распутать беспорядок. См. Ответ Сэмма Купера. Я думаю, что я проголосовал только против еще одного ответа здесь, на SO, но этот определенно заслужил мой голос против.
Эндрю Стейтц
Какой беспорядок? Для чего вам нужны данные? Часто вам нужно только передать его напрямую какому-нибудь принтеру этикеток или тому подобному, и тогда вы можете просто рассматривать его как кусок текста. В других случаях вас могут интересовать города и почтовые индексы (но тогда вам лучше убедиться, что у вас есть клиенты только из поддерживаемых стран)
erikkallen
2
OP не упомянул, что «нужно только передать его на принтер этикеток», и на каждой моей работе мы использовали адрес как «данные», составляя отчеты, собирая налоги (налог с продаж в Колорадо для приборов, устанавливаемых в новом доме. варьируются от одной стороны улицы к другой), назначение потенциальных клиентов продавцам, соблюдение государственных требований, список можно продолжать и продолжать. «Уничтожение» данных (путем объединения отдельных элементов в одно поле или отказа от сбора доступных данных) является «грехом» в моей книге и всегда оказывалось кошмаром, о котором я предупреждал, когда люди игнорировали меня.
Эндрю Стейтц,
Если позже вы обнаружите, что вам не нужны данные, вы всегда можете «уничтожить» их позже. «Создание» данных варьируется от кошмарного (разделение информации на отдельные поля) до невозможного (сбор данных постфактум). Если бы ОП сказал: «Нужно только отправить его на принтер этикеток», я бы аплодировал и проголосовал за ваш ответ. Однако без конкретного упоминания чего-то подобного предложение «уничтожить» данные, ИМО, граничит с безответственностью или даже подлостью.
Эндрю Стейтц
Там, где я работал (в основном в электронной коммерции), мы, как правило, храним ее в 5-6 разных полях, но мы никогда и никогда ничего не делаем с информацией, кроме как использовать ее для отправки на доставку.
erikkallen