Есть ли какие-либо хорошие ссылки на передовые методы хранения почтовых адресов в СУБД? Кажется, есть много компромиссов, которые можно сделать, и множество плюсов и минусов для каждого из них, которые нужно оценить - конечно, это делалось снова и снова? Может, кто-то хоть что-то написал, где-то извлечены уроки?
Примеры компромиссов, о которых я говорю, - это сохранение почтового индекса в виде целого числа по сравнению с полем char, если номер дома будет сохранен как отдельное поле или часть адресной строки 1, если номера апартаментов / квартир / и т. Д. Будут нормализованы или просто сохранены как кусок текста в адресной строке 2, как вы обрабатываете zip +4 (отдельные поля или одно большое поле, целое число или текст)? и т.п.
На данный момент я в первую очередь озабочен адресами в США, но я полагаю, что есть некоторые передовые практики в отношении того, чтобы подготовить себя к возможному выходу на глобальный уровень (например, соответствующее название полей, таких как регион вместо штата или почтовый индекс вместо почтового индекса, и т.п.
Ответы:
Для более широкого международного использования одна схема, которую следует рассмотреть, - это та, которая используется Drupal Address Field . Он основан на стандарте xNAL и, кажется, охватывает большинство международных случаев. Немного покопавшись в этом модуле, вы обнаружите несколько хороших жемчужин для интерпретации и проверки адресов на международном уровне. Он также имеет хороший набор административных районов (провинция, штат, область и т. Д.) С кодами ISO.
Вот суть схемы, скопированной со страницы модуля:
Уроки, которые я усвоил:
locality
&thoroughfare
.источник
Для «международного» пользователя нет ничего более неприятного, чем иметь дело с веб-сайтом, ориентированным только на адреса в американском формате. Поначалу это немного грубо, но становится серьезной проблемой, когда проверка также чрезмерно усердна.
Если вы озабочены выходом на мировой рынок, единственный совет, который я могу дать, - сохранять свободную форму. В разных странах действуют разные условные обозначения - в некоторых номер дома ставится перед названием улицы, в некоторых - после. У некоторых есть штаты, некоторые регионы, некоторые округа, некоторые их комбинации. Здесь, в Великобритании, почтовый индекс - это не почтовый индекс, это почтовый индекс, содержащий как буквы, так и цифры.
Я бы посоветовал просто ~ 10 строк строк переменной длины вместе с отдельным полем для почтового индекса (и будьте осторожны, как вы это описываете, чтобы справиться с национальной чувствительностью). Позвольте пользователю / покупателю решить, как писать свои адреса.
источник
Если вам нужна исчерпывающая информация о том, как в других странах используются почтовые адреса, вот очень хорошая справочная ссылка (Колумбийский университет):
Руководство Франка по эффективной адресации почтовых адресов
для международной почты
источник
Вам определенно следует подумать о том, чтобы сохранить номер дома в виде символьного поля, а не числа, из-за особых случаев, таких как "половинные числа" или мой текущий адрес, который похож на "129A", но A не считается квартирой. номер службы доставки.
источник
Я сделал это (строго смоделировал адресные структуры в базе данных) и больше никогда не буду этого делать. Вы не представляете, насколько безумны исключения, которые, как правило, приходится учитывать.
Я смутно припоминаю некоторую проблему с норвежскими почтовыми индексами (я думаю), у которых было все четыре позиции, кроме Осло, где было 18 или около того.
Я абсолютно уверен, что с того момента, как мы начали использовать географически правильные почтовые индексы для всех наших национальных адресов, довольно много людей начали жаловаться на то, что их почта пришла слишком поздно. Оказалось, что эти люди жили недалеко от границы между почтовыми зонами, и, несмотря на то, что кто-то действительно проживал в почтовой зоне, скажем, 1600, на самом деле его почта должна быть адресована на почтовый ящик 1610, потому что на самом деле это была та соседняя почтовая зона. это на самом деле послужило ему, поэтому отправка его почты в его правильный почтовый ящик займет на пару дней больше времени из-за нежелательного вмешательства, которое потребовалось в правильном почтовом отделении, чтобы отправить его в неправильный почтовый ящик ...
(В итоге мы зарегистрировали этих людей с адресом за границей в стране с кодом ISO «ZZ».)
источник
Вы обязательно должны проконсультироваться с « Хорошим ли это способом моделирования адресной информации в реляционной базе данных », но ваш вопрос не является прямым дубликатом этого.
Несомненно, есть много уже существующих ответов (например, посмотрите примеры моделей данных на DatabaseAnswers ). Многие из ранее существовавших ответов при некоторых обстоятельствах являются дефектными (если вообще не выбирать ответы БД).
Один из основных вопросов, который следует учитывать, - это объем адресов. Если ваша база данных должна иметь дело с международными адресами, вы должны быть более гибкими, чем если бы вам приходилось иметь дело только с адресами в одной стране.
На мой взгляд, это часто (что не означает всегда ) разумно записывать «изображение метки адреса» адреса и отдельно анализировать содержимое. Это позволяет вам справиться с различиями в размещении почтовых индексов, например, между разными странами. Конечно, вы можете написать анализатор и форматировщик, которые справятся с эксцентриситетом разных стран (например, адреса в США имеют 2 или 3 строки; напротив, британские адреса могут иметь значительно больше; один адрес, на который я пишу периодически, имеет 9 строк). Но может быть проще поручить людям выполнять анализ и форматирование, а СУБД просто хранить данные.
источник
Если вы не собираетесь вычислять номера улиц или почтовые индексы, вы просто вызываете будущую боль, сохраняя их в виде чисел.
Вы можете сэкономить несколько байтов здесь и там и, возможно, получить более быстрый индекс, но что вы делаете, когда почта США или любая другая страна, с которой вы имеете дело, решает ввести альфы в коды?
Стоимость дискового пространства будет намного дешевле, чем стоимость его починки позже ... y2k кого-нибудь?
источник
В дополнение к тому, что сказали @ Джонатан Леффлер и @ Пол Фишер
Если вы когда-нибудь ожидаете, что к вашим требованиям будут добавлены почтовые адреса Канады или Мексики, сохранение
postal-code
в виде строки является обязательным. В Канаде есть буквенно-цифровые почтовые индексы, и я даже не помню, как выглядит Мексика.источник
Я обнаружил, что самый простой способ - перечислить все возможные поля от наименьшей дискретной единицы до наибольшей. Пользователи будут заполнять поля, которые сочтут нужными. Моя таблица адресов выглядит так:
источник
Где "компромисс" при хранении ZIP в виде ЧИСЛА или VARCHAR? Это просто выбор - это не компромисс, если нет преимуществ для обоих, и вам нужно отказаться от некоторых преимуществ, чтобы получить другие.
Если сумма почтовых индексов вообще не имеет никакого значения, почтовые индексы как число бесполезны.
источник
Это может быть излишним, но если вам нужно решение, которое будет работать с несколькими странами, и вам нужно программно обрабатывать части адреса:
у вас может быть обработка адресов для конкретной страны с помощью двух таблиц: одна общая таблица с 10 столбцами VARCHAR2, 10 столбцами с номерами, другая таблица, которая сопоставляет эти поля с приглашениями, и имеет столбец страны, связывающий структуру адреса со страной.
источник
Если вам когда-либо придется подтверждать адрес или использовать его для обработки платежей по кредитным картам, вам понадобится хотя бы небольшая структура. Блок текста произвольной формы не подходит для этого.
Почтовый индекс - это обычное необязательное поле для проверки транзакций с платежной картой без использования всего адреса. Поэтому имейте для этого отдельное поле большого размера (не менее 10 символов).
источник
На основе ответов базы данных
источник
Я бы просто поместил все поля вместе в большое поле NVARCHAR (1000) с элементом textarea, чтобы пользователь мог ввести значение (если вы не хотите выполнять анализ, например, почтовых индексов). Все эти вводы в адресной строке 1, адресной строке 2 и т. Д. Просто раздражают, если у вас есть адрес, который не соответствует этому формату (и, как вы знаете, есть другие страны, кроме США).
источник