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

каков правильный тип столбца для удержания ZipCode значения

6
postgresql sqldatatypes zipcode

3 ответов

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

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

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 синтаксис регулярных выражений.

7

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

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

мое мнение:

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

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

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

0