Je suis en train de concevoir un schéma de base de données et je me contente d'utiliser nvarchar pour les types de données de ma colonne textuelle (pour le support unicode). Bien que je ne m'attends pas à un texte non-anglais, je pense qu'il vaudrait mieux le soutenir dès le début, au cas où.Y at-il une raison pour laquelle je ne devrais pas utiliser NVARCHAR dans Sql Server?
Y a-t-il une raison pour laquelle je devrais rester avec varchar? Performance?
Oui, performance, en taille. nvarchar prend plus de bytes, je pense que c'est double (corrigez-moi si je me trompe) et c'est à cause du support unicode. Donc, si vous n'avez pas besoin de support Unicode, allez avec varchar.
Dans le monde i18n d'aujourd'hui, nvarchar a beaucoup de sens. varchar peut avoir du sens pour les données spécifiées pour ne pas être unicode (peut-être avez-vous des champs système qui doivent être ASCII).
J'utilise nvarchar par défaut pour des choses comme les noms, les descriptions, les adresses, etc.
varchar est plus petit, donc il y a peut-être des économies IO avec varchar sur nvarchar (mais notez que le code page devient plus gros problème aussi).
Aussi, voir cette question: VARCHAR vs NVARCHAR performance.
Personnellement, je dis tiens à varchar (comme je répondais dans ce fil). Il y a un surcoût de performance non trivial.
Nous utilisons VARCHAR pour presque tout, et NVARCHAR seulement très très occasionnellement.
Codes produit ne ont pas besoin nVarChar - nous ne permettons pas autre chose que AZ, 0-9 et « _ » dans les ...
Son espace de stockage deux fois, mais aussi que la moitié de la entrées par page d'index (et par page de données) et la moitié du cache mémoire est "gaspillé", plus de cycles CPU pour comparer les données, et ainsi de suite.
IME les accents étrangers couramment utilisés travaillent uniquement dans Varchar (c'est-à-dire LATIN-1). Nous n'avons pas l'intention de faire des jeux de caractères chinois ou alternatifs, et quand nous serons en mesure de gérer ce jeu de caractères en utilisant NVarchar dès le premier jour, nous serons le moindre de nos soucis - Alignement droit-à-gauche ou vertical du texte. :(
Et si vous avez autorisé NVarchar pour, disons, un nom, comment allez-vous taper le caractère étendu à partir de votre clavier? Et si vous importez les données (il est déjà NVarchar) comment allez-vous capable de rechercher ce client en utilisant votre clavier QWERTY standard Beaucoup de choses impliquées dans l'internationalisation d'une application, donc mon opinion est qu'il n'y a aucun intérêt à "l'utiliser en utilisant NVarchar"
Mais là encore beaucoup d'endroits I aller à avoir NVarchar ... et la plupart des colonnes sont aussi de 50 caractères .... ils doivent savoir quelque chose sur la croissance de la population et les plans d'expansion pour les codes postaux que je n'ai pas !!
Comme déjà mentionné, le le compromis est l'avenir contre la performance. Dans mon expérience, SQL Server fait assez bien avec des limitations de CPU et de mémoire plus faibles, mais lui donne un I/O de disque lent et il peut vraiment chug.
Si vous ne prévoyez pas de jeux de caractères codés sur deux octets (caractères chinois), utilisez VARCHAR (MAX).
D'une manière générale; Commencez avec le type de données le plus cher qui a le moins de contraintes. Mettez-le en production. Si les performances commencent à poser un problème, découvrez ce qui est réellement stocké dans ces colonnes nvarchar. Y a-t-il des caractères qui ne rentrent pas dans varchar? Sinon, passez à varchar. N'essayez pas de pré-optimiser avant de savoir où est la douleur. Ma conjecture est que le choix entre nvarchar/varchar n'est pas ce qui va ralentir votre application dans un avenir prévisible. Il y aura d'autres parties de l'application où l'optimisation des performances vous donnera beaucoup plus pour les dollars.
Je voudrais ajouter la version de SQL Server à votre question, cela peut faire une différence? – Ash
J'utilise sql server 2005 actuellement mais nous cherchons à passer à 2008 finalement. – mmcdole