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

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

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

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

Anil G

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

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

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

Номера деталей (и все, что не имеет единиц измерения) не являются "числовыми". Это просто цепочка цифр.

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

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

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

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

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

SELECT * FROM my_table WHERE integer_as_string > '100';

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

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

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

Это может быть прочитано как восьмеричное значение Если оно правильно прочитано как десятичное значение, оно превращается в "700" Когда вы получите значение «700», не забудьте добавить ноль. Если вы не добавляете ноль позже, как вы узнаете, что «700» - это «0700», или кто-то неправильно набрал «7100»? Технически наши почтовые индексы представляют собой настоящие строки, даже если они всегда четырехзначные.

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

Но как насчет сохранения количества файлов в торренте? Целое число или строка?

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

Если идентификатор когда-либо будет начинаться с нуля, сохраните его как целое число.

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

1. Вы не сможете правильно выполнять сравнения. "... where x> 500" не то же самое, что ".. where x> '500'", потому что "500"> "100000"
2. Строка с точки зрения производительности, это будет хитом, особенно если вы используете индексы в качестве целочисленных индексов. намного быстрее, чем строковые индексы.

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

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

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

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

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

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

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