У меня есть значения id для продуктов, которые мне нужны для хранения. Сейчас они все целые числа, но я не уверен, что поставщик данных в будущем будет вводить буквы или символы в этот микс, поэтому я обсуждаю, хранить ли его сейчас как целое или строку.
Есть ли производительность или другие недостатки для сохранения значений в виде строк?
Если вам действительно не нужны функции целого числа (то есть возможность делать арифметику), то, вероятно, вам лучше хранить идентификаторы продуктов в виде строк. Вам никогда не придется делать что-либо вроде добавления двух идентификаторов продукта вместе или вычислять среднее значение для группы идентификаторов продуктов, поэтому нет необходимости в действительном числовом типе.
Маловероятно, что сохранение идентификаторов продуктов в виде строк приведет к заметной разнице в производительности. Хотя будет небольшое увеличение размера хранилища, размер строки идентификатора продукта, скорее всего, будет намного меньше, чем данные в остальной части вашей строки базы данных.
Сохранение идентификаторов продуктов в виде строк сегодня сэкономит вам много боли в будущем, если поставщик данных решит начать использовать буквенные или символьные символы. Нет реального недостатка.
НЕ рассматривайте производительность. Рассмотрим смысл.
Идентификационные номера "не являются числовыми, за исключением того, что они записаны с алфавитом всех цифр.
Если у меня есть номер детали 12 и номер 14, в чем разница между ними? Является ли часть № 2 или -2 значимой? Нет.
Номера деталей (и все, что не имеет единиц измерения) не являются "числовыми". Они всего лишь цифры цифр.
Почтовые индексы в США, например. Телефонные номера. Номера социального страхования. Это не цифры. В моем городе разница между почтовым индексом 12345 и 12309 - это не расстояние от моего дома до центра города.
Не объединяйте числа - с единицами - где суммы и различия означают что-то со строками цифр без сумм или различий.
Идентификаторы номеров - правильные строки. Не целые числа. Они никогда не будут целыми, потому что у них нет сумм, различий или средних значений.
Это действительно зависит от того, о каком типе вы говорите. Если это код, подобный номеру телефона, на самом деле было бы лучше использовать varchar для идентификатора, а затем ваш собственный идентификатор будет серийным для db и использовать для первичного ключа. В случае, когда целое число не имеет численного значения, обычно предпочтительны varchars.
Я только что провел последний год, имея дело с базой данных, в которой есть почти все идентификаторы как строки, некоторые с цифрами, а другие - смешанные. Это проблемы:
Конечно, если у вас закончились идентификаторы или вы не знаете, как создавать новые идентификаторы, ваше приложение будет мертвым. Я предлагаю, чтобы, если вы не можете контролировать формат входящих идентификаторов, вам нужно создать свои собственные (числовые) идентификаторы и связать с ним предоставленный ID. Затем вы можете убедиться, что ваш собственный идентификатор является надежным и уникальным (и цифровым), но предоставляет идентификатор пользователя, который может иметь любой формат, который требуется вашим пользователям, и даже не должен быть уникальным во всем приложении. Это больше работает, но если бы вы прошли через то, что у меня было, вы бы знали, куда идти.
Anil G
Я не уверен, насколько хорошие базы данных сравнивают, является ли одна строка большей, чем другая, например, с целыми числами. Попробуйте выполнить такой запрос:
SELECT * FROM my_table WHERE integer_as_string > '100';
Пространство, которое будет занимать целое число, будет намного меньше, чем строка. Например, 2 ^ 32-1 = 4 294 967 295. Это займет 10 байтов для хранения, где в качестве целого будет занимать 4 байта для хранения. Для одной записи это не очень много места, но когда вы начинаете миллионы... Как и многие другие сообщения, есть несколько других проблем, которые следует учитывать, но это один из недостатков строкового представления.
С другой стороны, это действительно зависит от вашей ситуации. Если вы собираетесь хранить что-то вроде телефонных номеров или номеров регистрации учащихся, то имеет смысл использовать строки.
Целые функции более эффективны с точки зрения хранения и производительности. Однако, если есть вероятность, что альфа-символы могут быть введены, вы должны использовать строку. На мой взгляд, эффективность и производительность могут быть незначительными, тогда как время, необходимое для изменения вашего кода, может быть не таким.
Как указано в Integer vs String в базе данных
В моей стране пост-коды также всегда 4 цифры. Но первая цифра может быть равна нулю.
Если вы сохраняете "0700" как целое число, вы можете получить массу проблем:
Он может быть прочитан как восьмеричное значение Если он правильно читается как десятичное значение, он превращается в "700" , Когда вы получите значение "700" , вы должны помнить, что нужно добавить нуль Я не добавляю нуль, позже, как вы узнаете, "700" - "0700", или кто-то ошибся "7100"? Технически наши почтовые коды являются фактическими строками, даже если они всегда 4 цифры.
Вы можете сохранить их как целые числа, чтобы сэкономить место. Но помните, что это простой DB-трюк, и будьте осторожны с ведущими нулями.
Но как насчет того, сколько файлов находится в потоке? Целое или строка?
Это явно целое число.
Если идентификатор всегда начинался с нуля, сохраните его как в межсетевом.
Лучше использовать независимый идентификатор и, если необходимо, добавить идентификатор строки: если вам нужно указать бизнес-индикатор, зачем его использовать ID системы?
Основные недостатки:
Целочисленные операции и индексирование всегда показывают лучшую производительность при больших масштабах данных (более 1 тыс. строк в таблице, не говоря уже о связанных таблицах)
Вам нужно будет сделать дополнительные проверки, чтобы ограничить только числовые значения в столбце: это может быть регулярное выражение на стороне клиента или базы данных. Во всяком случае, вам нужно как-то гарантировать, что там действительно целое.
И вы создадите дополнительный контекстный уровень для разработчиков, чтобы знать, и в любом случае кто-то всегда будет это испортить:)