Любые недостатки для хранения целого числа в виде строки в базе данных?

Ответ 1

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

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

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

Ответ 2

НЕ рассматривайте производительность. Рассмотрим смысл.

Идентификационные номера "не являются числовыми, за исключением того, что они записаны с алфавитом всех цифр.

Если у меня есть номер детали 12 и номер 14, в чем разница между ними? Является ли часть № 2 или -2 значимой? Нет.

Номера деталей (и все, что не имеет единиц измерения) не являются "числовыми". Они всего лишь цифры цифр.

Почтовые индексы в США, например. Телефонные номера. Номера социального страхования. Это не цифры. В моем городе разница между почтовым индексом 12345 и 12309 - это не расстояние от моего дома до центра города.

Не объединяйте числа - с единицами - где суммы и различия означают что-то со строками цифр без сумм или различий.

Идентификаторы номеров - правильные строки. Не целые числа. Они никогда не будут целыми, потому что у них нет сумм, различий или средних значений.

Ответ 3

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

Ответ 4

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

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

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

Anil G

Ответ 5

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

SELECT * FROM my_table WHERE integer_as_string > '100';

Ответ 6

Пространство, которое будет занимать целое число, будет намного меньше, чем строка. Например, 2 ^ 32-1 = 4 294 967 295. Это займет 10 байтов для хранения, где в качестве целого будет занимать 4 байта для хранения. Для одной записи это не очень много места, но когда вы начинаете миллионы... Как и многие другие сообщения, есть несколько других проблем, которые следует учитывать, но это один из недостатков строкового представления.

Ответ 7

• Вы не сможете делать сравнения правильно. "... где x > 500" не то же самое, что ".. где x > " 500 ", потому что" 500 " > " 100000 "
• Эффективная строка будет хитом, особенно если вы используете индексы в виде целых индексов намного быстрее, чем индексы строк.

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

Ответ 8

Целые функции более эффективны с точки зрения хранения и производительности. Однако, если есть вероятность, что альфа-символы могут быть введены, вы должны использовать строку. На мой взгляд, эффективность и производительность могут быть незначительными, тогда как время, необходимое для изменения вашего кода, может быть не таким.

Ответ 9

Как указано в Integer vs String в базе данных

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

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

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

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

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

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

Если идентификатор всегда начинался с нуля, сохраните его как в межсетевом.

Ответ 10

Лучше использовать независимый идентификатор и, если необходимо, добавить идентификатор строки: если вам нужно указать бизнес-индикатор, зачем его использовать ID системы?

Основные недостатки:

• Целочисленные операции и индексирование всегда показывают лучшую производительность при больших масштабах данных (более 1 тыс. строк в таблице, не говоря уже о связанных таблицах)

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

• И вы создадите дополнительный контекстный уровень для разработчиков, чтобы знать, и в любом случае кто-то всегда будет это испортить:)