Целое число против строки в базе данных

Question

При определении типов данных в базе данных у меня всегда была проблема с выбором, использовать ли целые числа или строки для хранения определенных «числовых» данных.

Скажите, что я строю Пока что Другой Адрес Книга и есть поле для почтового индекса При условии, что почтовые индексы всегда 4-значное число, для какого типа данных я буду их хранить? Целое число или строка? Технически это целое число, но я не делаю никаких вычислений, я просто выкладываю его в таблицу. Изменится ли ваше мнение, если я хочу отсортировать таблицу по почтовому индексу?

Так вот, я не дура. Я признаю действительную потребность в целых числах, таких как просмотры страниц и уникальные пользователи или зарегистрированные пользователи и гостевые пользователи. Но как насчет хранения количества файлов в торренте? Целое число или строка?

Answer 1

Всегда важно понимать семантику данных, с которыми вы работаете. Позвольте мне объяснить это на примере.

Считайте, что хотите сохранить ПИН в своей базе данных. Чтобы ответить, какой тип данных вы должны использовать, вы должны сначала ответить, что на самом деле означает PIN-код ( Персональный идентификационный номер ).

1. Если это действительно число, как на самом деле указывает его имя, то я не вижу причин, по которым его не следует представлять в виде целого числа.

   Некоторые люди могут утверждать, что вы не можете различить 0001 и 01. Очевидно, они не считают ПИН-кодом число, и если они работают с такой семантикой, им следует использовать строку.

   Примечание. Если длина ПИН-кода будет фиксированной, скажем, до 4 цифр, они все равно могут использовать целое число, поскольку любое число всегда будет заполняться начальными нулями и будет точно таким же (0001 будет таким же, как 01) - но эти ограничения фиксированной длины типичны для чисел, чтобы избежать неправильного ввода.

2. Если в семантике четко указано, что ПИН является числом, т. Е. Что ПИН 0001 точно такой же, как ПИН 01, я бы использовал целочисленное представление.

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

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

У вас есть данные, и вы хотите их сохранить, представить как-то - просто подумайте, с чем вы работаете.

Answer 2

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

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

Возьмем наш случай, когда у нас есть географический идентификатор, который представляет собой заполненное нулями 4-значное «числовое» значение. Это поле часто используется для объединения таблиц.

Я бы выбрал один из двух подходов: 1) объявите столбец как поле типа char длиной 4 и добавьте CONSTRAINT LIKE '[09] [09] [09] [09]' 2) определите его как числовую длину 4 и, если пользователи захотят, отформатируйте значение только при отображении.

Цифровой подход 1 избавляет вас от необходимости постоянного форматирования, что не составляет особого труда, но если вы часто фильтруете и даже индексируете / объединяете столбец, я бы сказал, что у нас нет варианта №2.

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

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

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

У меня нет проблем с вариантом № 1, за исключением использования поля в индексе и моей озабоченности подходом, когда вы принимаете поле как афа-число, люди склонны добавлять в него больше мусора.

Взять, к примеру, наш идентификатор сотрудника Peoplesoft. Кто-то решил добавить «X» перед «числом», заполненным нулями, состоящим из 6 символов, чтобы обозначить, что работник является подрядчиком. Это нарушает мою личную практику не объединять отдельные части информации в одно поле. Это вызвало всевозможные проблемы несоответствия в разных системах. Если бы это поле было числовым, никто бы не попытался это сделать.

Комментарии

Answer 3

Иногда «всегда» означает «на следующий месяц». Я бы не стал рассчитывать на то, что 4-значные коды не будут буквенно-цифровыми в течение срока моей ответственности.

Некоторые диалекты SQL поддерживают тип данных, подобный NUMBER (4). Это работает как строка символов, но алфавит от 0 до 9.

Answer 4

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

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

Answer 5

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

Итог - если вы не выполняете арифметику, возможно, это не совсем число.