Найкращі практики зберігання поштових адрес у базі даних (RDBMS)?

Чи є якісь посилання на кращі методи зберігання поштових адрес у RDBMS? Здається, існує безліч вигід, які можна здійснити, і багато плюсів і мінусів, які можна оцінити кожному - напевно, це робилося знову і знову? Може, хтось хоч десь написав, що десь засвоїв уроки?

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

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

Для більш міжнародного використання одна з розглянутих схем - це та, яку використовує поле Drupal Address . Він заснований на стандарті 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" ​​- але А не вважається квартирою номер служби доставки.

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

Я тумано згадую якусь проблему з норвезькими поштовими індексами (я думаю), які були усіма 4 позиціями, крім Осло, в якому було 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 у вигляді НОМЕРА чи ВАРХАРУ? Це лише вибір - це не розпродаж, якщо немає вигод для обох, і вам доведеться відмовитися від деяких вигод, щоб отримати інші.

Якщо сума кліпів взагалі не має жодного значення, блискавки як число не корисні.

Це може бути зайвим, але якщо вам потрібно рішення, яке б працювало з кількома країнами, і вам потрібно програмно обробити частини адреси:

Ви можете мати обробку адрес для кожної країни за допомогою двох таблиць: Одна загальна таблиця з 10 стовпцями VARCHAR2, 10 стовпцями номерів, інша таблиця, яка відображає ці поля підказки, і стовпець країни прив'язує структуру адреси до країни.

Якщо вам коли-небудь доведеться підтвердити адресу або використовувати її для обробки платежів кредитною карткою, вам, принаймні, потрібна невелика структура. Блок тексту тексту у вільній формі не дуже підходить для цього.

Поштовий індекс - це загальне необов’язкове поле для перевірки транзакцій платіжними картками без використання всієї адреси. Отже, майте для цього окреме і щедро розмірене поле (принаймні 10 символів).

Натхненний відповідями бази даних

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Я б просто поклав всі поля разом у велике поле NVARCHAR (1000) з текстовим елементом для користувача, який повинен ввести значення для (якщо ви не хочете провести аналіз, наприклад, поштові індекси). Усі ці вхідні рядки 1, адресний рядок 2 і т. Д. Просто набридають, якщо у вас є адреса, яка не добре відповідає цьому формату (і, ви знаєте, є інші країни, крім США).