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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вдохновленный Database Answers

 Line1 Line2 Line3 City Country_Province PostalCode CountryId OtherDetails 

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

  • Создание серии дат - использование типа даты в качестве входных данных
  • Что делает ключевое слово `forall` в Haskell / GHC?
  • Использование IsAssignableFrom с открытыми типами
  • Какой тип данных использовать для hashированного поля пароля и какой длины?
  • Типы в MySQL: BigInt (20) против Int (20)
  • Типы данных PostgreSQL и C #
  • java: конвертировать float в String и String для float
  • Полезно ли использовать целочисленный столбец для хранения почтовых индексов США в базе данных?
  • Определить тип файла изображения
  • Преобразование hex в текстовое представление в десятичное число
  • Когда следует использовать std :: size_t?
  • Давайте будем гением компьютера.