Мені потрібно зберігати поштові індекси в базі даних. Наскільки колонка повинна бути великою?

103

Я очікую, що стовпець буде VARCHAR2 в моїй базі даних Oracle.

США-блискавки - 9.

Канадський - 7.

Я думаю, що 32 символи були б розумною верхньою межею

Що я пропускаю?

[EDIT] TIL: 12 - це розумна відповідь на питання. Дякую всім, хто зробив свій внесок.

— EvilTeach
джерело

Корисне посилання, проте його точність може бути трохи поза. EG він перелічує австралійські поштові індекси як 7 символів, а насправді їх 4. Посилання: en.wikipedia.org/wiki/Postcodes_in_Australia та список поштових індексів, доступний на веб- сайті www1.auspost.com.au/postcodes .

— rossp

re: мій попередній коментар - це не означає, що цей список не корисний як посібник. Якщо припустити помилки списку на стороні більш довгих поштових індексів, найдовша довжина становить 9 символів, тому 16 символів або місця повинні дати вам багато місця для дихання.

— rossp

Також список країн трохи короткий. Я впевнений, що на планеті є більше країн, ніж перелічені ...

— Роберт Коритник

2

За даними en.wikipedia.org/wiki/List_of_postal_codes , найдовший - 12 символів, якщо ви зберігаєте "-", а інше 11

— Ніл МакГуйган

@CMS: Можливо, ви хочете оновити посилання на цю сторінку Вікіпедії , схоже, це буде детальніше.

— Вайк Гермеч

51

Прослідуючи на сторінці Поштових кодів Вікіпедії , 32 символи повинні бути більш ніж достатніми. Я б сказав, що навіть 16 символів - це добре.

— більш сильний
джерело

8

Гарне посилання. Навіть якщо допустити розділові знаки в США ZIP + 4, 10 символів вистачить для будь-якої країни, наскільки я міг сказати.

— Джонатан Леффлер

На основі цього посилання, зі сторінки, пов’язаної вище, я б поїхав із 18, щоб розмістити такі країни, як Чилі: en.wikipedia.org/wiki/List_of_postal_codes

— mopo922

5

Чилі - 7 символів. Веб-сторінка, на яку ви посилаєтесь, просто відображає розділові знаки.

— EvilTeach

21

Як уже зазначав @ neil-mcguigan, у wikipedia є пристойна сторінка з цієї теми. На основі цього 12 символів повинні це зробити: http://en.wikipedia.org/wiki/List_of_postal_codes

У статті вікіпедії перелічено ~ 254 країни, що досить добре щодо УПУ (Універсального поштового союзу) має 192 країни-члени.

— Вайк Гермеч
джерело

2

Зауважте, що Монтсеррат - це лише 8 символів, 1110-1350 позначає діапазон. Discovermni.com/about-montserrat/montserrat-post-codes

— Vajk Hermecz

Можливо, Вікіпедія потребує редагування, оскільки аналогічний поштовий індекс для Мальти має такий загальний тип, як "AAA NNNN". Я не заперечую, щоб було навіть 15 символів, тому що це може бути менше проблеми лише пізніше, якщо нам доведеться коригувати довжину стовпців, також при правильному використанні типів даних, він все одно не повинен приймати всі 15 символів (можливо, вархар або nvarchar чи подібне?) .

— Манохар Редді Поредді

12

Чому б ви оголосили розмір поля більшим за фактичні дані, які ви очікуєте для зберігання в ньому?

Якщо початкова версія вашої заявки буде підтримувати американські та канадські адреси (що я випливаю з того, що ви називаєте ці розміри у своєму запитанні), я оголошу це поле як VARCHAR2 (9) (або VARCHAR2 ( 10) якщо ви збираєтесь зберігати дефіс у полі ZIP + 4). Навіть дивлячись на пости, які інші вносили до поштових індексів у різних країнах, VARCHAR2 (9) або VARCHAR2 (10) буде достатнім для більшості, як не для всіх інших країн.

Унизу лінії завжди можна змінити стовпчик, щоб збільшити довжину, якщо виникне потреба. Але взагалі важко запобігти комусь, десь із тієї чи іншої причини вирішити зробити "креативом" і ввести 50 символів у поле VARCHAR2 (50) (тобто тому, що вони хочуть іншого рядка на етикетці доставки). Ви також маєте справу з тестуванням крайових випадків (чи буде кожна програма, яка відображає ZIP, обробляти 50 символів?). І з тим, що коли клієнти отримують дані з бази даних, вони, як правило, розподіляють пам’ять на основі максимального розміру даних, які будуть отримані, а не фактичної довжини заданого рядка. Напевно, це не велика справа в цьому конкретному випадку, але 40 байт в ряд може стати пристойним шматком оперативної пам’яті для деяких ситуацій.

Крім того, ви можете також розглянути можливість зберігання (принаймні для адрес США) поштового індексу та розширення +4 окремо. Зазвичай корисно мати змогу генерувати звіти за географічним регіоном, і ви, можливо, часто захочете скласти все у поштовий індекс, а не розбивати його на розширення +4. У цей момент корисно не намагатися ПІДТРІЛИТИ перші 5 символів для поштового індексу.

— Джастін Печера
джерело

4

Що ж, якщо припустити, що ми кодуємо щось нерозумно, як Pro * C, наявність поля, достатньо великого для зростання, означає, що код не потрібно зачіпати у разі збільшення використання.

— EvilTeach

Так, розбиття нам поштового коду на 5 і 4 цифри може мати сенс, залежно від того, для чого ви плануєте його використовувати. Наприклад, якщо ви робите якусь відповідність адреси, ви можете спершу встановити відповідність на zip5 і вирішити неоднозначні ситуації з поштовим індексом 9. Це також допомагає використовувати код країни

— EvilTeach

3

Те, що вам не вистачає, є причиною, чому вам потрібно поштовий індекс обробляти спеціально.

Якщо вам цього не потрібно РОБОТА з поштовим індексом, я запропонував би не турбуватися про це. Під роботою я маю на увазі робити спеціальну обробку, а не просто використовувати для друку адресних міток тощо.

Просто створіть три або чотири адресних поля VARCHAR2 (50) [наприклад] і дозвольте користувачеві ввести все, що він хоче.

Вам дійсно потрібно групувати свої замовлення чи транзакції за поштовим індексом? Я думаю, що ні, оскільки різні країни мають надзвичайно різні схеми для цієї галузі.

— paxdiablo
джерело

Я згоден. Використовуючи поле VARCHAR2, реальність стосується такого поля, як поштовий індекс, який насправді не має значення. Трохи завеликий краще, ніж дратувати одного клієнта, оскільки він не може ввести свої дані.

— Тобі Аллен

І варчари зручні, оскільки бази даних (принаймні DB2) можуть оптимізувати їх зберігання, щоб не витрачати місця на зберігання.

— paxdiablo

1

можна зазначити, що сортування за країною та поштовим індексом призведе до зниження дешевших поштових тарифів у деяких місцях.

— EvilTeach

10

Не згоден. Колись внизу лінії, ви вирішите, що вам потрібно буде перевірити адреси у вашій базі даних (наприклад, для виправлення друкарських помилок та помилок введення даних), і тоді ви знайдете користь від правильної побудови моделі даних, а не просто засунути все в відра.

— Гері Майєрс

1

@Pax Якщо ви передаєте об'ємну пошту в Royal Mail, призначений районним районом (перша літера / два листи) поштового індексу, то ви можете доставити її MailSort, що дешевше звичайної пошти другого класу. Це лише один приклад.

— Річард Ґадсден

3

Нормалізація? Поштові індекси можуть використовуватися не один раз і можуть бути пов’язані з назвами вулиць чи назвами міст. Окрема таблиця (и).

— Стефан Еггермонт
джерело

Цікаво. Інша точка зору просто заборонена, без причини. +1

— EvilTeach

Як правило, поштовий індекс посилається на блок з одного боку вулиці. Щоб знайти ширший регіон, ви вибрали б першу половину поштового індексу. Маючи цю інформацію в окремій таблиці, насправді нічого не допоможе, і було б складніше підтримувати.

— RevNoah

4

@EvilTeach: Я думаю, що це було неприйнятним, тому що це поза темою. Чи говорить вам, наскільки великою повинна бути колонка для зберігання всіх можливих поштових індексів у світі? №

— wmax

2

Канадські поштові індекси - це лише 6 символів у вигляді літер та цифр (LNLNLN)

— tegbains
джерело

3

У середині канадських поштових індексів є порожній "ANA NAN" Thats 7 символів.

— EvilTeach

1

Але простір завжди посередині, тому зберігати його не потрібно.

— Graeme Perrow

1

Простір, схоже, не є частиною даних: "Примітка. Канадські поштові індекси завжди форматовані в одній послідовності: алфавітний символ / цифра / альфа / цифра / альфа / цифра (наприклад, K1A0B1)." Це з веб-сайту Canada Post.

— tegbains

2

Я не думаю, що втрата місця не має нічого спільного з «нормалізацією». Це лише проблема відображення. Як тире в номерах рахунків. Я б не зберігав його, і я б не покладався на нього для ідентифікації поштових індексів Канади, надаючи перевагу полю CountryCode (int), який можна індексувати. Відокремлення шару даних і презентацій - це правильний спосіб зробити це.

— Сем

2

Canada Post віддає перевагу місця в поштовому індексі під час звернення до конвертів. Найкраще зберігати його з простором та обробляти валідацію при вступі.

— RevNoah

2

Великобританія опублікувала стандарти: Каталог стандартів даних уряду Великобританії

Max 35 characters per line

Міжнародна поштова адреса:

Minimum of 2 lines and maximum of 5 lines for the postal delivery point 
details, plus 1 line for country and 1 line for postcode/zip code

Довжина поштового індексу Великобританії:

Minimum 6 and Maximum 8 characters

— PodTech.io
джерело

1

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

Усі інші подібні бази даних більш-менш ймовірно мають однакові дані та структуру. Вони просто видаляють зайву / зайву інформацію з бази даних. Якщо ви просто робите це для систем з низьким навантаженням, використовуйте їхні безкоштовні сервіси, обмеження привабливі та забезпечують більш простий інтерфейс за допомогою json та ajax. Ви можете переглянути межі тут

Для вашої інформації варчар (20) достатній для зберігання поштових індексів

— Джей Капасі
джерело