Символ по сравнению с Varchar если не всегда заполняется
У меня есть база данных с полем, которое содержит числа разрешения, связанные с запросами. Числа разрешения являются 13 цифрами, но разрешение не может быть выпущено.
После этих слов мне в настоящее время определяли поле как символ (13), который позволяет, АННУЛИРУЕТ. Меня попросили изменить его на varchar (13), потому что символ, если ноль, все еще использует полное.
Действительно ли это желательно? Кроме использования пространства, там какие-либо другие преимущества или недостатки к этому?
Я знаю в идеальной реляционной системе, числа разрешения были бы сохранены в другой связанной таблице для предотвращения использования ПУСТЫХ УКАЗАТЕЛЕЙ, но это - каково это.
4 ответа
Что ж, если вам не нужно использовать столько места, вы можете разместить в памяти больше страниц. Если вы сможете это сделать, ваша система будет работать быстрее. Это может показаться тривиальным, но я недавно настроил типы данных в таблице на клиенте, что уменьшило количество операций чтения на 25%, а ЦП - примерно на 20%.
Что касается того, с чем легче работать, следует отметить преимущества, упомянутые Дэвидом Стрэттоном. Я ненавижу использовать функции обрезки при построении струн.
Самое большое преимущество (в целом, не обязательно в вашем конкретном случае), о котором я знаю, это то, что в коде, если вы используете varchar, вам не нужно использовать функцию Trim каждый раз, когда вы хотите его отобразить. Я часто сталкиваюсь с этим, когда беру поля FirstName и LastName и объединяю их в FullName. Это просто раздражает и делает код менее читабельным.
если вы используете sql server 2008, вам следует обратить внимание на сжатие строк и, возможно, на разреженные поля, если в столбце более ~60% нулей.
Я бы оставил тип данных char(13), если все заполненные поля используют это количество.
Информация о сжатии строк: http://msdn.microsoft.com/en-us/library/cc280449.aspx
Разреженные столбцы: http://msdn.microsoft.com/en-us/library/cc280604.aspx
Если в поле всегда должно быть ровно 13 символов, я бы, вероятно, оставил его как CHAR (13).
Также интересное примечание от BOL:
Если SET ANSI_PADDING выключен, когда либо СОЗДАТЬ ТАБЛИЦУ или ИЗМЕНИТЬ ТАБЛИЦУ - это выполняется, столбец char, который определенный как NULL обрабатывается как varchar.
Изменить : Как часто вы ожидаете, что поле будет ПУСТО (NULL)? Если он будет заселяться 95% времени, вряд ли стоит вносить это изменение.