Тип столбца для ZipCode в базе данных PostgreSQL? - PullRequest
Новая
       11

Тип столбца для ZipCode в базе данных PostgreSQL?

6 голосов
/ 24 марта 2011

Каков правильный тип столбца для хранения ZipCode значений в PostgreSQL базе данных?

Ответы [ 3 ]

15 голосов
/ 10 сентября 2014

Я категорически не согласен с приведенным здесь советом.

  1. Принятый ответ принимает вещи, которые не являются цифрами.
  2. Вопрос касается почтовых индексов, а не почтовых индексов.
  3. Если мы предполагаем, что сообщение является неправильным и означает международные почтовые индексы, в международных почтовых индексах появляются символы, которых нет в этом списке, и многие международные, а также внутренние почтовые индексы США могут превышать десять символы
  4. Если мы действительно ответим на вопрос, который они задали, о почтовых индексах , то не должно быть места для чего-либо, кроме цифр (и, возможно, дефиса)
  5. Почтовые индексы США могут быть длиной до 11 цифр (13 символов, считая две черты) - есть нотация zip, zip + 4 и zip + 6 (которую программисты назвали бы zip + 4 + 2) нотацией; последний используется небоскребами, университетами и т. д.
  6. Почтовые индексы США всегда являются неотрицательными целыми числами и, следовательно, не должны храниться в виде текстовых данных, что приводит к проблемам неканонического представления не совпадают с почтовым индексом 203, который они случайно получили при постоянно ненужном разборе строковых представлений)
  7. Если вы притворяетесь, что действительно отслеживаете международные почтовые индексы, ограниченные текстовые поля с короткой последовательностью символов здесь даже не начинают работать. На ум приходит слово «Китай».

Мое мнение:

  1. Решите, используете ли вы почтовые индексы США или международные
  2. Если вы обрабатываете почтовые индексы США, отслеживайте их как целые числа без знака и добавляйте их слева в нули при отображении текста. (Вспомните временные метки Unix и локальные представления TZ, если вам нужно понять, почему это будет проще в долгосрочной перспективе.)
  3. Если вы работаете с международными почтовыми кодами, храните их в неограниченной строке в юникоде, привязывайте их к стране, которую они представляют, и проверяйте страну за страной с проверочными ограничениями. Эта проблема гораздо сложнее, чем кажется на первый взгляд. Международные адреса являются одними из наименее стандартизированных вещей на Земле. Подождите, вы узнаете, как работают японские номера домов, или почему в британском почтовом 6-коде есть пробелы.
7 голосов
/ 24 марта 2011

Это что-то вроде xxxxx-xxxx, поэтому рекомендуется varchar(10).

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

CREATE DOMAIN zipcode varchar(10) 
    CONSTRAINT valid_zipcode 
    CHECK (VALUE ~ '[A-Z0-9-]+'); -- or a better regular expression

Вы можете взглянуть на этот сайт, который предлагает следующее регулярное выражение: 

(^\d{5}(-\d{4})?$)|(^[ABCEGHJKLMNPRSTVXY]{1}\d{1}[A-Z]{1} *\d{1}[A-Z]{1}\d{1}$)

Но вы должны проверить, работает ли оно для PostgreSQL регулярного выражениясинтаксис.

0 голосов
/ 24 марта 2011

это зависит от того, какой почтовый индекс вы хотите.если вы уверены, что вам нужно будет сохранить только стандартную 5-значную цифру, тогда использование int будет наиболее экономно.

однако если вам нужно сделать расширенную 5 + 4, тогда поле из 10-значного символа будетЛучший.Я лично полагаю, что в будущем это будет проще, если вам в конечном итоге понадобится хранить международные почтовые индексы. 10-значный код охватывает практически все возможные форматы почтовых индексов, с которыми я сталкивался.

...