Integer vs String в базе данных

Ответ 1

В моей стране пост-коды также всегда 4 цифры. Но первая цифра может быть равна нулю.

Если вы сохраняете "0700" как целое число, вы можете получить массу проблем:

• Он может быть прочитан как восьмеричное значение
• Если он правильно читается как десятичное значение, он превращается в "700"
• Когда вы получите значение "700" , вы должны помнить, что нужно добавить нуль
• Я не добавлю нуль, позже, как вы узнаете, "700" - "0700", или кто-то ошибся "7100"?

Технически, наши почтовые коды на самом деле являются строками, даже если они всегда 4 цифры.

Вы можете сохранить их как целые числа, чтобы сэкономить место. Но помните, что это простой DB-трюк, и будьте осторожны с ведущими нулями.

Но как насчет того, сколько файлы находятся в потоке? Целое или строка?

Это явно целое число.

Ответ 2

Я всегда использую следующее правило:

Если вы планируете выполнять математические вычисления на нем (добавление/вычитание/etc), сделайте его целым или другим численным типом данных.

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

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

Ответ 3

на мой взгляд, для почтовых кодов вы должны использовать строки, потому что у вас могут быть почтовые коды, которые стоят с нулями (09100), и если вы будете использовать целые числа, это будет 9100: сортировка не проблема, потому что все еще есть алфавитный ( "09100" - "09101" ). Для хранения номеров файлов я ожидал бы межсетевого взаимодействия, поэтому у вас нет проблем с тем, чтобы сократить или уменьшить его число. Таким образом, целые строки vs зависят от вашего использования!

Ответ 4

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

Другими словами, поскольку вы никогда не будете использовать почтовый индекс в качестве номера, нет смысла хранить его как единое целое. Неважно, как выглядят данные, важно, что это такое. Является ли почтовый индекс числом? Нет, это строка символов, которая просто состоит из целых числовых символов. Поэтому почтовый код лучше всего хранить в виде строки.

Ответ 5

Почтовый код не является номером: это код или идентификатор. То же самое относится к телефонным номерам.

Количество файлов в торренте является целым числом.

Не в последнюю очередь, в этом случае вы можете создать CHECK CONSTRAINT LIKE '[09][09][09][09]', чтобы данные сохранялись на уровне базы данных.

Ответ 6

Что касается почтовых индексов, это типичный британский почтовый индекс:

EC2R 6PK

В университете мой лектор базы данных рассказал мне что-то, что застряло со мной и до сих пор удерживает 15 лет спустя:

Если вы выполняете на нем арифметику, храните это как число. В противном случае строка.

Честно говоря, я не думаю, что вы можете ошибиться в этом совете.

Очевидно, вы не выполняете арифметику на почтовых индексах, поэтому они являются строками.

Ответ 7

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

Что касается количества файлов внутри торрента, это должно быть целое число.

Ответ 8

Есть ли '0000' почтовый индекс? Является ли он отличным от "0"?

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

Ответ 9

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

Если вы не собираетесь делать математику, сделайте ее строкой.

Ответ 10

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

Ответ 11

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

Нижняя строка - если вы не выполняете арифметику, это, вероятно, не действительно число.

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Я бы взял один из двух подходов: 1) объявите столбец как поле char длины 4 и добавьте CONSTRAINT LIKE [09] [09] [09] [09] ' 2) определите его как числовую длину 4 и, если пользователи этого захотят, отформатируйте значение КОГДА ОТОБРАЖЕНИЕ только.

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

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

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

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

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

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

Комментарии?

Ответ 15

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

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

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

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

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

• Если в семантике четко указано, что PIN-код является числом, т.е. что PIN 0001 точно такой же, как PIN-код 01, я бы использовал целочисленное представление.

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

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

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