В чем преимущество использования varbinary над varchar здесь?

Некоторое время назад я задал вопрос о сортировке номеров иерархии/версии в SQL Server. ( Как я могу Сортировка столбца «Номер версии» с помощью запроса SQL Server).

Среди отправленных ответов была эта ссылка на Задача TSQL Coding с почти такой же головоломкой.

В решении SQL2000 автор продемонстрировал два варианта: один использует и возвращает varchar, а другой — varbinary. Автор объясняет, ЧТО он это делает, не объясняя, ПОЧЕМУ.

Итак, мой вопрос действительно в том, каковы основные отличия/преимущества (если таковые имеются) разницы в подходе? т.е. зачем использовать varbinary вместо varchar?

Я не стал публиковать код, так как он наиболее элегантно изложен в приведенной выше статье.


sql sql-server varchar varbinary
person James Wiseman    schedule 12.05.2011    source источник
comment
Я полагаю, что ожидается, что данные varbinary обычно будут потреблять меньше байтов (5), чем данные varchar (я думаю, 10 или 11) на часть исходной строки, и поэтому для очень большого количества компонентов или сравнения с происходит, он должен быть более эффективным. Но я также предполагаю, что для большинства пользователей не так много практических различий в эффективности.   -  person Damien_The_Unbeliever    schedule 12.05.2011
comment
@Damien: Приветствую тебя. Я был бы рад проголосовать и принять это как ответ! Сделает это, если вы решите сделать это задним числом.   -  person James Wiseman    schedule 12.05.2011
comment
Я бы предположил, что это потому, что результат должен использоваться для сортировки, а двоичный файл может быть более эффективным, поскольку ему не нужно беспокоиться о сопоставлении. Но не уверен, что это правда в целом, и даже если это правда, вообще не знаю, как это будет сравниваться с сортировкой строки с двоичным предложением collate.   -  person Martin Smith    schedule 12.05.2011

Ответы (2)


arrow_upward
17
arrow_downward

Я полагаю, что ожидается, что данные varbinary обычно будут потреблять меньше байтов (5), чем данные varchar (я думаю, 10 или 11) на часть исходной строки, и поэтому для очень большого количества компонентов или сравнения с происходит, он должен быть более эффективным.

Но я бы порекомендовал, если вы хотите использовать какое-либо решение, реализовать оба (они довольно короткие) и попробовать профилировать ваши реальные данные (и шаблоны запросов), чтобы увидеть, есть ли практические различия (я не ожидал такого).

(Crafty Steal): И, как указывает Мартин, бинарные сравнения будут более эффективными, поскольку они не будут задействовать весь код, предназначенный для обработки сопоставлений. :-)

person Damien_The_Unbeliever    schedule 12.05.2011

arrow_upward
5
arrow_downward

Если мы используем разные параметры сортировки для разных столбцов 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

Но если вы выберете однобайтовый набор символов (например, latin1) вместо многобайтового набора символов (например, 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.

person sudip    schedule 27.01.2018