Есть ли преимущество при настройке полей tinyint, если я знаю, что значение не будет превышать 255?

Question

Должен ли я выбрать наименьший возможный тип данных или, например, если я сохраняю значение 1, не имеет значения, какой тип данных col, и значение будет занимать тот же объем памяти?

Вопрос также в том, потому что мне всегда придется конвертировать его и играть в приложении.

---

UPDATE

Я думаю, что varchar (1) и varchar (50) - это один и тот же объем памяти, если значение равно "a", я подумал, что то же самое с int и tinyint, в соответствии с ответами, которые я понимаю, это не так, правда? 1010 *

Answer 1

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

Одна страница в Sql Server - 8 КБ. Использование маленьких целых вместо целых позволит вам разместить больше данных на одной странице, но вы должны решить, стоит ли это того. Если вы собираетесь отбивать тысячи обращений в минуту, тогда да. Если это хобби-проект или что-то, что увидят несколько десятков пользователей, тогда это не имеет значения.

Answer 2

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

---

Чтобы ответить на ваше обновление:

varchar занимает только столько места, сколько вы используете, и поэтому вы правы, когда говорите, что символ «а» будет занимать 1 байт (в латинской кодировке) независимо от размера поля varchar твой выбор. Это не относится к любому другому типу поля в SQL.

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

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

Answer 3

Традиционно каждый бит, сохраняемый в размере страницы, будет означать небольшое улучшение скорости: более узкие строки означают больше строк на страницу, что означает меньше потребляемой памяти и меньше запросов ввода-вывода, что приводит к лучшей скорости. Однако с SQL Server 2008 сжатие страниц все становится нечетким. Алгоритм сжатия может сжимать 4-байтовые числа со значениями менее 255 даже при меньшем байте.

Сжатие строк алгоритмы будут хранить 4 байта int в одном байте для значений меньше 127 (int подписано), 2 байта для значений меньше 32768 и т. Д. И т. Д.

Однако, учитывая, что приятные функции сжатия доступны только на серверах Enterprise Edition, имеет смысл сохранить привычку использовать наименьший возможный тип данных.

Answer 4

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