Рекомендации по хранению почтовых адресов в базе данных (РСУБД)?

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

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

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

ОТВЕТЫ

Ответ 1

Как "международный" пользователь, нет ничего более неприятного, чем работа с сайтом, ориентированным только на адреса только в формате США. Сначала это немного грубо, но становится серьезной проблемой, когда валидация также чрезмерно усердна.

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

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

Ответ 2

Для более международного использования одной схемой, которую следует учитывать, является поле адреса 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.

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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