Quel est l'avantage d'utiliser varbinary sur varchar ici?
il y a peu de temps, j'ai posé une question sur le tri des numéros de hiérarchie/version dans le serveur SQL. ( Comment puis-je Trier une colonne 'Numéro de Version' de manière générique en utilisant une requête SQL Server ).
parmi les réponses qui ont été soumises se trouvait ce lien à un défi de codage TSQL avec à peu près le même casse-tête .
dans la solution SQL2000 l'auteur a démontré deux variantes, l'une Utilisant et retournant un varchar et l'autre type varbinary. L'auteur explique qu'il le fait sans expliquer pourquoi.
donc, ma question est vraiment, quelles 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 son plus élégamment résumé dans l'article ci-dessus.
2 réponses
je crois que l'attente est que les données varbinary consommeront généralement moins d'octets (5), que le varchar un (10 ou 11, je pense) par portion de la chaîne originale, et donc, pour un très grand nombre de composants, ou des comparaisons à se produire, il devrait être plus efficace.
mais je recommande que si vous cherchez à utiliser l'une ou l'autre solution, que vous mettez en œuvre les deux (ils sont assez courts), et essayer un certain profilage par rapport à vos données réelles (et les modèles de requête), à voir s'il y a des différences pratiques (Je ne m'y attendais pas).
(Crafty Steal): et comme Martin le souligne, les comparaisons binaires seront plus efficaces, puisqu'elles n'impliqueront pas tout le code qui est là pour traiter les collations. :- )
si nous utilisons différentes collations pour différentes colonnes de varchar pour stocker des chaînes et utiliser plus d'une de ces colonnes dans une requête sql, alors la requête sql peut jeter l'erreur"mélange non valide de collations". ( Par exemple, si nous voulons comparer deux chaînes de collation incompatible ou essayer de sélectionner des données de collation différente dans une colonne combinée).
mais, cela peut être corrigé si nous spécifions "COLLATE" dans la requête. Par exemple:
WHERE 'A' COLLATE latin1_general_ci = 'A' COLLATE latin1_general_ci
But, cela va à l'encontre de tout indice que vous pourriez avoir.
pour nous prémunir contre les erreurs de" mélange non valide de collations", nous pouvons utiliser varbinary.
varbinary utilise moins d'espace que varchar si collation multi-octets est utilisé pour la colonne 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 d'encodages. Un classement est un ensemble de règles pour comparaison de 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 jeu de caractères à un seul octet (pour ex, latin1) au lieu d'un jeu de caractères à plusieurs octets (pour ex, utf8 ou ucs2), alors l'exigence d'espace pour varbinary et varchar sont les mêmes.
VARBINARY est meilleur que VARCHAR s'il n'y a pas de vérification de validité. Par exemple, si le jeu de caractères par défaut est UTF8 alors c'est illégal:
CREATE TABLE t9 (s1 VARCHAR(5));
INSERT INTO t9 VALUES (0xF4808283);
mais, c'est légal parce que le jeu de caractères n'a pas d'importance:
CREATE TABLE t10 (s1 VARBINARY(5));
INSERT INTO t10 VALUES (0xF4808283);
ainsi, VARCHAR compare les caractères en utilisant une" collation " et VARBINARY compare les octets. La plupart des classements sont "insensibles à la casse", de sorte que les majuscules et minuscules sont considérées comme égales. Puisque, varbinary n'utilise aucune collation, les opérations de recherche sont toujours sensibles à la casse en cas de varbinary.