Типы данных SQL Server: хранить 8-значное число без знака как INT или как CHAR (8)?

Question

я думаю, что название говорит обо всем. Что лучше (быстрее, экономить место в памяти и на диске), хранить 8-значные числа без знака как Int или как char (8)? Будут ли у меня проблемы, когда число изменится на 9 цифр в будущем, когда я буду использовать фиксированную длину символа?

Справочная информация: я хочу сохранить TAC s

Спасибо

Answer 1

Учитывая, что TAC могут иметь начальные нули, что они фактически являются непрозрачным идентификатором и никогда не рассчитываются с использованием столбца char.

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

Редактировать

Но чтобы избежать попадания мусора, убедитесь, что вы также применили ограничение CHECK. Например, если это должно быть 8 цифр, добавьте

CONSTRAINT CK_Only8Digits CHECK (not TAC like '%[^0-9]%' and LEN(RTRIM(TAC)) = 8)

Answer 2

Int будет использовать меньше места в памяти и даст более быструю индексацию, чем символ.

Если вам нужно разобрать эти числа - найдите все, где цифры 3-4 равны "02" или что-то подобное -- char будет проще и, вероятно, быстрее.

Я понимаю, что вы не делаете арифметику с ними.Вы не добавили бы два TAC вместе или не нашли бы среднее значение TAC для набора записей или чего-то подобного.Если бы вы были, это был бы аргумент slam-dunk для использования int.

Если они имеют начальные нули, вероятно, проще использовать char, так что вам не нужно всегда дополнять число нулями до правильногодлина.

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

Answer 3

Если это число, сохраните его как число.

Целые числа хранятся с использованием 4 байта , давая им диапазон:

-2 ^ 31 (-2 147 483 648) до 2 31-1 (2 147 483 647)

Итак, подходит для ваших нужд.

char[8] будет храниться как 8 байт , поэтому удваивайте объем памяти и, конечно, страдаете от необходимости расширения в будущем (преобразование почти 10 миллионов записей из 8 в 9 символов потребует времени и вероятно, потребуется перевести базу данных в автономный режим на время).

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

---

Обновление

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

Что касается проблемы с будущим расширением - поскольку char - это поле фиксированной длины, изменение с char[8] на char[9] не приведет к потере информации. Однако я не уверен, будет ли добавлен дополнительный символ справа или слева (хотя это, возможно, не определено). Вам нужно будет протестировать, и после расширения поля вам нужно будет убедиться, что исходные данные были сохранены.

Лучшим способом может быть создание нового поля char[9], перенос в него всех данных char[8] (для обеспечения надежности и согласованности), затем удаление поля char[8] и переименование нового поля в исходное. название. Конечно, это разрушит всю статистику в таблице (но так же приведет к прямому расширению поля).

Answer 4

Придерживайтесь INT для этого, ОПРЕДЕЛЕННО INT (ИЛИ БОЛЬШОЙ)

Посмотрите на int, bigint, smallint и tinyint (Transact-SQL)

Целочисленные (целые числа) данные от -2 ^ 31 (-2 147 483 648) - 2 ^ 31 - 1 (2147483647). Размер хранилища 4 байт,

bigint (целое число) данные от -2 ^ 63 (-9,223,372,036,854,775,808) через 2 ^ 63-1 (9 223 372 036 854 775 807). Размер хранилища составляет 8 байт.

по сравнению с

чар и варчар

Фиксированная длина не-Unicode символа данные длиной n байтов. n должно быть значение от 1 до 8000. Место хранения размер n байтов.

Кроме того, после того, как вы сделаете запрос на это, у вас снизится производительность, если вы будете использовать целые числа по сравнению с вашим столбцом char, поскольку SQL Server будет делать то же самое для вас ...