Quelles sont les principales différences de performance entre les types de données SQL Server varchar et nvarchar ?

Question

Je travaille sur une base de données pour une petite application web à mon école en utilisant SQL Server 2005 .
Je vois deux écoles de pensée sur la question des varchar vs nvarchar :

1. Utilisation varchar à moins que vous ne traitiez un grand nombre de données internationalisées, utilisez alors nvarchar .
2. Il suffit d'utiliser nvarchar pour tout.

Je commence à voir les mérites du point de vue 2. Je sais que nvarchar prend deux fois plus d'espace, mais ce n'est pas nécessairement un problème énorme puisque cela ne va stocker des données que pour quelques centaines d'étudiants. Il me semble qu'il serait plus simple de ne pas s'en préoccuper et de permettre à tout le monde d'utiliser nvarchar. Ou y a-t-il quelque chose qui m'échappe ?

Answer 1

L'espace disque n'est pas le problème, mais la mémoire et les performances le sont. Doublement des pages lues, doublement de la taille de l'index, étrange LIKE et = comportement constant, etc.

Avez-vous besoin de stocker du chinois, etc. script ? Oui ou non...

Et de MS BOL " Effets de l'Unicode sur le stockage et les performances "

Editer :

Question récente de l'OS soulignant à quel point les performances des nvarchar peuvent être mauvaises...

SQL Server utilise beaucoup de CPU lors de recherches dans des chaînes nvarchar

Answer 2

Utilisez toujours nvarchar.

Dans la plupart des applications, vous n'aurez peut-être jamais besoin des caractères à deux octets. Toutefois, si vous devez prendre en charge des langues à deux octets et que votre schéma de base de données ne prend en charge qu'un seul octet, il sera très coûteux de revenir en arrière et de modifier l'ensemble de votre application.

Le coût de la migration d'une application de varchar à nvarchar sera bien plus élevé que le peu d'espace disque supplémentaire que vous utiliserez dans la plupart des applications.

Answer 3

Soyez cohérent ! L'association d'un VARCHAR à un NVARCHAR a un impact important sur les performances.

Answer 4

Nvarchar va entraîner des frais généraux importants en termes de mémoire, de stockage, d'ensemble de travail et d'indexation, de sorte que si les spécifications l'imposent, il sera vraiment possible de le faire. jamais ne soit pas nécessaire, ne vous donnez pas la peine de le faire.

Je n'appliquerais pas de règle stricte "toujours nvarchar" car cela peut être un véritable gaspillage dans de nombreuses situations - en particulier pour l'ETL à partir d'ASCII/EBCDIC ou pour les colonnes d'identifiants et de codes qui sont souvent des clés et des clés étrangères.

D'un autre côté, il existe de nombreux cas de colonnes pour lesquels je m'assurerais de poser cette question dès le début et, si je n'obtenais pas de réponse claire et rapide immédiatement, je ferais en sorte que la colonne soit nvarchar.

Answer 5

Pour votre application, nvarchar convient car la taille de la base de données est faible. Dire "utilisez toujours nvarchar" est une simplification excessive. Si vous n'avez pas besoin de stocker des choses comme des Kanji ou d'autres caractères bizarres, utilisez VARCHAR, cela prendra beaucoup moins de place. Mon prédécesseur à mon poste actuel a conçu quelque chose en utilisant NVARCHAR alors que ce n'était pas nécessaire. Nous l'avons récemment remplacé par VARCHAR, ce qui nous a permis d'économiser 15 Go sur cette seule table (sur laquelle il y avait beaucoup d'écritures). En outre, si vous avez ensuite un index sur cette table et que vous souhaitez inclure cette colonne ou créer un index composite, vous venez d'augmenter la taille de votre fichier d'index.

Réfléchissez simplement à votre décision ; en matière de développement SQL et de définition des données, il semble qu'il y ait rarement une "réponse par défaut" (autre que d'éviter les curseurs à tout prix, bien sûr).