Quel est l'avantage de l'utilisation de varbinary sur varchar ici?

Il y a un moment, j'ai posé une question à propos de la hiérarchie/numéro de version tri dans SQL Server.
(
Comment puis-je Sorte Un "Numéro de Version' Colonne, de manière Générique à l'Aide d'une Requête SQL Server).

Parmi les réponses qui ont été soumis a été ce lien vers un TSQL Codage défi avec à peu près le même casse-tête.

Dans le SQL2000 solution, l'auteur a démontré une deux variantes, l'une utilisant et en retournant un type varchar et l'autre de type varbinary. L'auteur explique QU'il est en train de faire cela, sans expliquer POURQUOI.

Donc, ma question est vraiment, quelles sont les principales différences/avantages (le cas échéant) de la différence d'approche? I. e. pourquoi utiliser un varbinary au lieu d'un varchar?

J'ai omis de poster le code, comme la plupart des élégamment résumé dans l'article ci-dessus.

  • Je crois que l'espoir est que les données varbinary seront généralement consommer moins d'octets (5), que le type varchar (10 ou 11, je pense) par portion de la chaîne d'origine, et donc, pour un très grand nombre de composants, ou des comparaisons de se produire, elle devrait être plus efficace. Mais je voudrais aussi deviner qu'il n'y a pas beaucoup de différences pratiques en matière d'efficacité, pour la plupart des utilisateurs.
  • Bravo pour cela. J'aurais été heureux de upvote et accepter que comme une réponse! Le fera si vous choisissez de le faire que de manière rétrospective.
  • J'aurais cru que c'est parce que le résultat est à être utilisé pour le tri et le binaire peut être plus efficace car il n'a pas à se préoccuper de classement. Mais pas sûr que cela est vrai en général, et même si c'est vrai en général aucune idée de comment il serait comparer tri d'une chaîne avec un binaire collate clause.
InformationsquelleAutor James Wiseman | 2011-05-12
  1. 14

    Je crois que l'espoir est que les données varbinary seront généralement consommer moins d'octets (5), que le type varchar (10 ou 11, je pense) par portion de la chaîne d'origine, et donc, pour un très grand nombre de composants, ou des comparaisons de se produire, elle devrait être plus efficace.

    Mais je recommande que si vous cherchez à utiliser une ou l'autre solution, que vous en oeuvre à la fois (ils sont assez courts), et d'essayer un peu de profilage à l'encontre de vos données réelles (et les modèles de requête), pour voir si il y a des différences pratiques (je ne m'attends pas tellement).

    (Astucieux Voler): Et comme Martin, les comparaisons binaires sera plus efficace, car il ne sera pas impliquer tout le code qui est là pour résoudre les classements. 🙂

    InformationsquelleAutor Damien_The_Unbeliever
  2. 4

    Si nous utilisons classement différent pour les différentes colonnes varchar pour stocker des chaînes et l'utilisation de plus d'une de ces colonnes dans une requête sql, puis la requête sql peut jeter l'erreur "Invalid mélange de classements". ( Par ex, si l'on veut comparer deux chaînes de caractères incompatibles, de classement ou d'essayer de sélectionner des données de classement différent dans un combiné de colonne).

    Mais, qui peut être résolu si l'on précise "RASSEMBLER" dans la requête. Ex :

     WHERE 'A' COLLATE latin1_general_ci = 'A' COLLATE latin1_general_ci

    Mais, cela va à l'encontre de tout INDICE que vous pourriez avoir.

    Pour se prémunir contre le "mix Invalide de classements" des erreurs, nous pouvons utiliser varbinary.

    varbinary utilise moins d'espace que varchar si multi-octets classement est utilisé pour la colonne de type varchar. (chaînes binaires n'ont pas de jeux de caractères et collations. Les chaînes binaires sont simplement une séquence de valeurs d'octets).

    *** Btw, Un jeu de caractères est un ensemble de symboles et de codages. Un classement est un ensemble de règles pour la comparaison des caractères dans un jeu de caractères https://dev.mysql.com/doc/refman/5.7/en/charset-general.html

    Mais, si vous choisissez un seul byte character set (par ex, latin1) au lieu de multi-byte character set (par ex, utf8 ou ucs2), puis l'espace requis pour les deux varbinary et varchar sont les mêmes.

    VARBINARY est mieux que VARCHAR si il n'y a pas de vérification de la validité.
    Par exemple, si le jeu de caractères par défaut est UTF-8 alors que c'est illégal:

    CREATE TABLE t9 (s1 VARCHAR(5));
INSERT INTO t9 VALUES (0xF4808283);

    Mais, c'est légal, parce que jeu de caractères n'a pas d'importance:

    CREATE TABLE t10 (s1 VARBINARY(5));
INSERT INTO t10 VALUES (0xF4808283);

    Donc, VARCHAR compare les caractères à l'aide d'un "classement" et VARBINARY comparer octets. La plupart des classements sont "insensibles à la casse", de sorte que les majuscules et minuscules sont considérées comme égales. Depuis, varbinary ne pas utiliser un classement quelconque, les opérations de recherche sont toujours sensibles à la casse en cas de varbinary.

    InformationsquelleAutor sudip