Каковы варианты использования выбора CHAR вместо VARCHAR в SQL?

Char немного быстрее, поэтому, если у вас есть столбец, который, как вы ЗНАЕТЕ, будет определенной длины, используйте char. Например, запоминание (M) ale / (F) emale / (U) неизвестно для пола или 2 символов для штата США.

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

при использовании значений varchar SQL Server требует дополнительных 2 байта на строку для хранения некоторой информации об этом столбце, тогда как если вы используете char, это не нужно так что если вы

Общее правило - выбрать СИМВОЛ, если все строки будут близки к такая же длина. Выберите VARCHAR (или NVARCHAR), когда длина варьируется значительно. CHAR также может быть немного быстрее, потому что все строки имеют одинаковую длину.

Это зависит от реализации БД, но обычно VARCHAR (или NVARCHAR) использует еще один или два байта памяти (для длины или завершения) в дополнение к фактическим данным. Итак (при условии, что вы используете однобайтовый набор символов), сохраняя слово «FooBar»

• СИМВОЛ (6) = 6 байт (без накладных расходов)
• ВАРЧАР (100) = 8 байт (2 байта накладных расходов)
• СИМВОЛ (10) = 10 байт (4 байта отходов)

Нижняя строка: СИМВОЛ, может, Быстрее и более компактный для данных относительно одинаковой длины (в пределах двух символов разницы в длине).

Примечание: Microsoft SQL имеет 2 байта служебных данных для VARCHAR. Это может варьироваться от БД к БД, но обычно требуется как минимум 1 байт служебных данных для указания длины или EOL в VARCHAR.

Как было указано Гавен в комментариях: все меняется, когда дело доходит до наборов многобайтовые символы, и это тот случай, когда VARCHAR становится гораздо лучшим выбором.

Примечание о заявленной длине VARCHAR: поскольку он хранит длину фактического содержимого, вы не теряете неиспользованную длину. Таким образом, для хранения 6 символов в VARCHAR (6), VARCHAR (100), или же VARCHAR (МАКС) используется такой же объем памяти. Узнайте больше о различиях при использовании VARCHAR (МАКС.). Вы объявляете размер максимум в VARCHAR, чтобы ограничить объем хранимого.

В комментариях AlwaysLearning указал, что Документы Microsoft Transact-SQL, похоже, говорит об обратном. Я бы предположил, что это ошибка или, по крайней мере, документы неясны.

Я поддерживаю комментарий Джима МакКита.

Кроме того, индексация и полное сканирование таблицы выполняются быстрее, если в таблице есть только столбцы типа CHAR. По сути, оптимизатор сможет предсказать размер каждой записи, если в ней есть только столбцы CHAR, при этом ему необходимо проверить значение размера каждого столбца VARCHAR.

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

Но вы, вероятно, не будете заботиться о снижении производительности, если ваша таблица не будет огромной.

Помните мудрые слова Джикстры. Ранняя оптимизация производительности - корень всех зол.

В некоторых базах данных SQL VARCHAR будет дополнен до максимального размера, чтобы оптимизировать смещения. Это необходимо для ускорения полного сканирования таблиц и индексов.

Из-за этого у вас нет экономии места при использовании VARCHAR (200) по сравнению с CHAR (200)

Существует разница между оптимизацией производительности на раннем этапе и использованием правил передового опыта. Если вы создаете новые таблицы, в которых всегда будет поле фиксированной длины, имеет смысл использовать CHAR, вы должны использовать его в этом случае. Это не ранняя оптимизация, а реализация практического правила (или передовой практики).

т.е. - Если у вас есть двухбуквенное поле состояния, используйте CHAR (2). Если у вас есть поле с фактическими именами состояний, используйте VARCHAR.

Если вы работаете со мной и работаете с Oracle, я, вероятно, заставлю вас использовать varchar почти в любых обстоятельствах. Предположение о том, что char использует меньшую вычислительную мощность, чем varchar, может быть верным ... на данный момент ... но механизмы баз данных со временем становятся лучше, и такое общее правило создало будущий "миф".

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

Заключительная мысль: я видел всевозможные проблемы с использованием CHAR, людей, которые ищут «когда они должны искать», или людей, которые ищут «FOO», когда им следует искать «FOO» (здесь куча пробелов) ', или люди, не обрезающие конечные пробелы, или ошибки с Powerbuilder, добавляющие до 2000 пробелов к значению, которое он возвращает из процедуры Oracle.

Помимо повышения производительности, CHAR может использоваться для обозначения того, что все значения должен имеют одинаковую длину, например, столбец для сокращений штатов США.

Я бы выбрал varchar, если столбец не хранит фиксированное значение, такое как код штата США, который всегда составляет 2 символа, а список действительного кода штатов США не часто меняется :).

В любом другом случае, даже при хранении хешированного пароля (фиксированной длины), я бы выбрал varchar.

Почему - столбец типа char всегда заполняется пробелами, поэтому столбец my_column определяется как char (5) со значением 'ABC' внутри сравнения:

my_column = 'ABC' -- my_column stores 'ABC  ' value which is different then 'ABC'

ложный.

Этот особенность может привести к множеству раздражающих ошибок во время разработки и усложнить тестирование.

Есть преимущества в производительности, но вот одно из них, о котором не упоминалось: миграция строк. С помощью char вы заранее резервируете все пространство. Допустим, у вас есть char (1000) и вы храните 10 символов, вы используете все 1000 символов пространства. В varchar2 (1000) вы будете использовать только 10 символов. Проблема возникает, когда вы изменяете данные. Допустим, вы обновили столбец, и теперь он содержит 900 символов. Возможно, что в текущем блоке нет места для расширения varchar. В этом случае механизм БД должен перенести строку в другой блок и сделать указатель в исходном блоке на новую строку в новом блоке. Теперь для чтения этих данных движку БД необходимо будет прочитать 2 блока. Никто не может однозначно сказать, что varchar или char лучше. Есть место для компромисса по времени и рассмотрения того, будут ли обновляться данные, особенно если есть большая вероятность, что они будут расти.

Это классический компромисс между пространством и производительностью.

В MS SQL 2005 Varchar (или NVarchar для языков, требующих двух байтов на символ, например китайский) имеют переменную длину. Если вы добавите строку после того, как она была записана на жесткий диск, данные будут размещены в несоответствующем месте исходной строки и приведут к фрагментации ваших файлов данных. Это повлияет на производительность.

Итак, если пространство не является проблемой, тогда Char лучше для производительности, но если вы хотите уменьшить размер базы данных, тогда лучше использовать varchars.

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

Когда дело доходит до типов БД, стоит отметить интересную вещь: sqlite (популярная мини-база данных с довольно впечатляющей производительностью) помещает все в базу данных в виде строки и набирает на лету.

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

Многие люди отмечали, что использование CHAR дает некоторые преимущества, если вы знаете точную длину значения. Но хотя сохранение штатов США в виде CHAR (2) сегодня прекрасно, когда вы получаете сообщение от продаж, что «мы только что совершили нашу первую продажу в Австралию», вы попадаете в мир боли. Я всегда присылаю, чтобы переоценить, сколько, по моему мнению, должно быть полей, вместо того, чтобы делать «точное» предположение для покрытия будущих событий. VARCHAR даст мне больше гибкости в этой области.

CHAR занимает меньше места для хранения, чем VARCHAR, если все значения данных в этом поле имеют одинаковую длину. Теперь, возможно, в 2009 году база данных 800 ГБ будет такой же для всех целей и задач, как 810 ГБ, если вы преобразовали VARCHAR в CHAR, но для коротких строк (1 или 2 символа), я бы сказал, что CHAR по-прежнему является отраслевой "лучшей практикой".

Теперь, если вы посмотрите на широкий спектр типов данных, которые большинство баз данных предоставляют даже для одних целых чисел (bit, tiny, int, bigint), ЕСТЬ причины выбрать один из них. Простой выбор bigint каждый раз на самом деле немного игнорирует цели и способы использования поля. Если поле просто представляет возраст человека в годах, bigint будет излишним. Это не обязательно «неправильно», но это неэффективно.

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

Фрагментация. Char резервирует место, а VarChar - нет. Разделение страниц может потребоваться для размещения обновления до varchar.

Использование CHAR (NCHAR) и VARCHAR (NVARCHAR) приводит к различиям в способах хранения данных сервером базы данных. Первый вводит завершающие пробелы; Я столкнулся с проблемой при использовании его с оператором LIKE в функциях SQL SERVER. Поэтому я должен постоянно использовать VARCHAR (NVARCHAR).

Например, если у нас есть таблица ТЕСТ (ID INT, статус CHAR (1)), и вы пишете функцию для вывода списка всех записей с некоторым конкретным значением, например следующим:

CREATE FUNCTION List(@Status AS CHAR(1) = '')
RETURNS TABLE
AS
RETURN
SELECT * FROM TEST
WHERE Status LIKE '%' + @Status '%'

В этой функции мы ожидаем, что при установке параметра по умолчанию функция вернет все строки, но на самом деле это не так. Измените тип данных @Status на VARCHAR, чтобы решить проблему.

Я бы НИКОГДА не использовал символы. У меня были эти дебаты со многими людьми, и они всегда вспоминают устаревшее клише, что чар быстрее. Ну я говорю, насколько быстрее? О чем мы здесь говорим, миллисекундах, секундах и если да, то сколько? Вы говорите мне, что, поскольку кто-то утверждает, что это на несколько миллисекунд быстрее, мы должны внести в систему тонны трудно исправляемых ошибок?

Итак, вот некоторые проблемы, с которыми вы можете столкнуться:

Каждое поле будет дополнено, так что вы навсегда получите код с RTRIMS повсюду. Это также огромная трата дискового пространства для более длинных полей.

Теперь предположим, что у вас есть типичный пример поля char, состоящего только из одного символа, но это поле является необязательным. Если кто-то передает в это поле пустую строку, оно становится одним пробелом. Поэтому, когда другое приложение / процесс запрашивает его, они получают один-единственный пробел, если они не используют rtrim. У нас были XML-документы, файлы и другие программы, отображающие только один пробел в необязательных полях и нарушающие работу.

Итак, теперь вы должны убедиться, что вы передаете в поле char нули, а не пустую строку. Но это НЕ правильное использование null. Вот использование null. Допустим, вы получили файл от поставщика.

Имя | Пол | Город

Боб || Лос-Анджелес

Если пол не указан, вы вводите в таблицу Боб, пустую строку и Лос-Анджелес. Теперь предположим, что вы получили файл, и его формат изменился, а пол больше не включен, но был в прошлом.

Имя | Город

Боб | Сиэтл

Что ж, поскольку пол не включен, я бы использовал null. Варчары поддерживают это без проблем.

Char, с другой стороны, другое дело. Вы всегда должны отправлять null. Если вы когда-нибудь отправите пустую строку, вы получите поле с пробелами.

Я мог бы продолжать и продолжать со всеми ошибками, которые мне приходилось исправлять с помощью символов и примерно за 20 лет разработки.