В чем преимущество использования varbinary перед varchar?
Некоторое время назад я задал вопрос о сортировке по иерархии / номеру версии в SQL Server. ( Как я могу отсортировать столбец "Номер версии" в общем, используя запрос SQL Server).
Среди представленных ответов была эта ссылка на задачу TSQL Coding с почти такой же загадкой.
В решении SQL2000 автор продемонстрировал два варианта: один с использованием и возвращением varchar, а другой с использованием varbinary. Автор объясняет, ЧТО он делает, не объясняя ПОЧЕМУ.
Итак, мой вопрос действительно, каковы основные различия / преимущества (если таковые имеются) различия в подходе? Т.е. зачем использовать varbinary вместо varchar?
Я пропустил публикацию кода, поскольку он наиболее элегантно описан в статье выше.
2 ответа
Я полагаю, что ожидание состоит в том, что данные varbinary, как правило, будут потреблять меньше байтов (5), чем один varchar (думаю, 10 или 11) на порцию исходной строки, и, таким образом, для очень большого числа компонентов или сравнений с происходят, это должно быть более эффективным.
Но я бы порекомендовал, если вы хотите использовать любое из этих решений, чтобы вы реализовали оба (они довольно короткие) и попробовали провести профилирование на основе ваших реальных данных (и шаблонов запросов), чтобы увидеть, есть ли практические различия (я не ожидал бы так).
(Crafty Steal): И, как указывает Мартин, бинарные сравнения будут более эффективными, так как в них не будет задействован весь код, который используется для сопоставления.:-)
Если мы используем разные параметры сортировки для разных столбцов varchar для хранения строк и используем более одного такого столбца в запросе SQL, запрос SQL может выдать ошибку "Недопустимое сочетание параметров сортировки". (Например, если мы хотим сравнить две строки несовместимого сопоставления или попытаться выделить данные другого сопоставления в объединенный столбец).
Но это можно исправить, если указать в запросе "COLLATE". Например:
WHERE 'A' COLLATE latin1_general_ci = 'A' COLLATE latin1_general_ci
Но это побеждает любой ИНДЕКС, который вы можете иметь.
Чтобы защититься от ошибок "Неверное сочетание параметров сортировки", мы можем использовать varbinary.
varbinary использует меньше места, чем varchar, если для столбца varchar используется многобайтовая сортировка. (двоичные строки не имеют наборов символов и параметров сортировки. Двоичные строки - это просто последовательность байтовых значений).
*** Кстати, набор символов - это набор символов и кодировок. Сличение - это набор правил для сравнения символов в наборе символов https://dev.mysql.com/doc/refman/5.7/en/charset-general.html
Но если вы выберете однобайтовый набор символов (для ex, latin1) вместо многобайтового набора символов (для ex, utf8 или ucs2), то требования к пространству для varbinary и varchar одинаковы.
VARBINARY лучше, чем VARCHAR, если нет проверки достоверности. Например, если набор символов по умолчанию - UTF8, то это недопустимо:
CREATE TABLE t9 (s1 VARCHAR(5));
INSERT INTO t9 VALUES (0xF4808283);
Но это законно, потому что набор символов не имеет значения:
CREATE TABLE t10 (s1 VARBINARY(5));
INSERT INTO t10 VALUES (0xF4808283);
Итак, VARCHAR сравнивает символы, используя "сопоставление", а VARBINARY сравнивает байты. Большинство сопоставлений "нечувствительны к регистру", поэтому верхний и нижний регистры считаются равными. Поскольку varbinary не использует никакое сопоставление, операции поиска всегда чувствительны к регистру в случае varbinary.