Quelle est la différence entre varchar et nvarchar?

https://stackoverflow.com/questions/144283

02-07-2019
|

Question

Est-ce simplement que nvarchar prend en charge les caractères multi-octets? Si tel est le cas, y a-t-il vraiment un intérêt, en dehors des problèmes de stockage, à utiliser varchars ?

La solution

Une colonne nvarchar peut stocker toutes les données Unicode. Une colonne varchar est limitée à une page de code de 8 bits. Certaines personnes pensent que varchar devrait être utilisé car il prend moins de place. Je crois que ce n'est pas la bonne réponse. Les incompatibilités entre les pages de code sont pénibles et Unicode est le remède contre les problèmes de page de code. Avec les disques et la mémoire bon marché de nos jours, il n’ya vraiment aucune raison de perdre du temps à fouiller dans les pages de codes.

Tous les systèmes d'exploitation et plates-formes de développement modernes utilisent Unicode en interne. En utilisant nvarchar plutôt que varchar , vous pouvez éviter de procéder à des conversions de codage à chaque lecture ou écriture dans la base de données. Les conversions prennent du temps et sont sujettes aux erreurs. Et la récupération d’erreurs de conversion est un problème non trivial.

Si vous vous connectez à une application qui utilise uniquement du code ASCII, je vous recommanderais quand même d'utiliser Unicode dans la base de données. Les algorithmes de classement des systèmes d'exploitation et des bases de données fonctionneront mieux avec Unicode. Unicode évite les problèmes de conversion lors de l'interfaçage avec d'autres systèmes. Et vous vous préparerez pour l'avenir. Et vous pouvez toujours valider que vos données sont limitées à l'ASCII 7 bits, quel que soit le système existant que vous avez à gérer, tout en bénéficiant des avantages du stockage Unicode intégral.

Autres conseils

varchar : longueur variable , données de caractères non-Unicode. Le classement de la base de données détermine la page de code dans laquelle les données sont stockées.

nvarchar : longueur variable Données de caractères Unicode. Dépend du classement de la base de données pour les comparaisons.

Fort de cette connaissance, utilisez celle qui correspond à vos données d'entrée (ASCII v. Unicode).

J'utilise toujours nvarchar car cela permet à tout ce que je construis de supporter à peu près toutes les données que je lui envoie. Mon système CMS utilise le chinois par accident, car j’ai utilisé nvarchar. De nos jours, les nouvelles applications ne devraient pas vraiment être concernées par la quantité d’espace requise.

Cela dépend de la manière dont Oracle a été installé. Au cours du processus d'installation, l'option NLS_CHARACTERSET est définie. Vous pourrez peut-être le trouver avec la requête SELECT valeur $ FROM sys.props $ WHERE name = 'NLS_CHARACTERSET' .

Si votre NLS_CHARACTERSET est un codage Unicode comme UTF8, tant mieux. L'utilisation de VARCHAR et de NVARCHAR est pratiquement identique. Arrêtez de lire maintenant, allez-y. Sinon, ou si vous n'avez aucun contrôle sur le jeu de caractères Oracle, lisez la suite.

VARCHAR - Les données sont stockées dans le codage NLS_CHARACTERSET. S'il existe d'autres instances de base de données sur le même serveur, vous pouvez être limité par elles; et vice versa, puisque vous devez partager le réglage. Un tel champ peut stocker toutes les données pouvant être codées à l'aide de ce jeu de caractères, et rien d'autre . Ainsi, par exemple, si le jeu de caractères est MS-1252, vous ne pouvez stocker que des caractères tels que des lettres anglaises, une poignée de lettres accentuées et quelques autres (comme € et -). Votre application ne serait utile que dans quelques endroits, incapable de fonctionner ailleurs dans le monde. Pour cette raison, il est considéré comme une mauvaise idée.

NVARCHAR - Les données sont stockées dans un codage Unicode. Chaque langue est supportée. Une bonne idée.

Qu'en est-il de l'espace de stockage? VARCHAR est généralement efficace, car le jeu de caractères / codage a été conçu sur mesure pour une langue spécifique. Les champs NVARCHAR sont stockés au format UTF-8 ou UTF-16, selon le réglage de NLS assez ironiquement. UTF-8 est très efficace pour " Western " langues, tout en prenant en charge les langues asiatiques. Le format UTF-16 est très efficace pour les langues asiatiques, tout en prenant en charge le "occidental". langues. Si vous êtes préoccupé par l'espace de stockage, choisissez un paramètre NLS pour obliger Oracle à utiliser UTF-8 ou UTF-16 selon les cas.

Qu'en est-il de la vitesse de traitement? La plupart des nouvelles plates-formes de codage utilisent Unicode de manière native (Java, .NET, voire C ++ std :: wstring d'il y a des années!). Par conséquent, si le champ de base de données est VARCHAR, il oblige Oracle à convertir les jeux de caractères entre chaque lecture et écriture, ce qui n'est pas très bon. L'utilisation de NVARCHAR évite la conversion.

Conclusion: utilisez NVARCHAR! Cela évite les limitations et les dépendances, convient très bien pour l’espace de stockage et, en règle générale, également pour les performances.

nvarchar stocke les données au format Unicode. Par conséquent, si vous prévoyez de stocker des données multilingues (plusieurs langues) dans une colonne de données, vous avez besoin de la variante N.

Mes deux cents

Les index peuvent échouer s'ils n'utilisent pas les types de données appropriés:
Dans SQL Server: Lorsque vous avez un index sur une colonne VARCHAR et que vous le présentez sous forme de chaîne Unicode, SQL Server ne l'utilise pas. La même chose se produit lorsque vous présentez un BigInt à une colonne indexée contenant SmallInt. Même si le BigInt est suffisamment petit pour être un SmallInt, le serveur SQL ne peut pas utiliser l'index. L’inverse ne vous pose pas ce problème (lorsque vous fournissez SmallInt ou Ansi-Code à une colonne BigInt ot NVARCH indexée).
Les types de données peuvent varier d'un SGBD à l'autre (système de gestion de base de données):
Sachez que chaque base de données a des types de données légèrement différents et que VARCHAR ne signifie pas la même chose partout. Alors que SQL Server contient VARCHAR et NVARCHAR, une base de données Apache / Derby ne contient que VARCHAR et VARCHAR est au format Unicode.

Principalement nvarchar stocke des caractères Unicode et varchar des caractères non Unicode.

" Unicodes " signifie un schéma de codage de caractères 16 bits permettant aux caractères de beaucoup d'autres langues comme l'arabe, l'hébreu, le chinois et le japonais d'être codés dans un seul jeu de caractères.

Cela signifie qu'unicodes utilise 2 octets par caractère pour stocker et que les non-unicodes n'utilisent qu'un octet par caractère à stocker. Ce qui signifie que les unicodes ont besoin d'une double capacité de stockage par rapport aux non-unicodes.

Vous avez raison. nvarchar stocke des données Unicode tandis que varchar stocke des données de caractères sur un octet. Autres que les différences de stockage ( nvarchar nécessite deux fois plus d'espace de stockage que varchar ), ce que vous avez déjà mentionné, la principale raison de préférer nvarchar à varchar serait une internationalisation (c'est-à-dire le stockage de chaînes dans d'autres langues).

Je dirais que cela dépend.

Si vous développez une application de bureau, où le système d'exploitation fonctionne en Unicode (comme tous les systèmes Windows actuels) et si la langue prend en charge nativement Unicode (les chaînes par défaut sont Unicode, comme en Java ou en C #), utilisez nvarchar.

Si vous développez une application Web, dans laquelle les chaînes sont au format UTF-8, et le langage utilisé est PHP, qui ne prend toujours pas en charge Unicode de manière native (dans les versions 5.x), varchar sera probablement un meilleur choix.

nVarchar vous aidera à stocker les caractères Unicode. C’est la voie à suivre si vous souhaitez stocker des données localisées.

Si un seul octet est utilisé pour stocker un caractère, il existe 256 combinaisons possibles. Vous pouvez ainsi enregistrer 256 caractères différents. La collation est le modèle qui définit les caractères et les règles selon lesquelles ils sont comparés et triés.

1252, qui est le latin1 (ANSI), est le plus commun. Les jeux de caractères à un octet ne permettent pas non plus de stocker tous les caractères utilisés par de nombreuses langues. Par exemple, certaines langues asiatiques ont des milliers de caractères, elles doivent donc utiliser deux octets par caractère.

norme Unicode

Lorsque des systèmes utilisant plusieurs pages de codes sont utilisés sur un réseau, il devient difficile de gérer les communications. Pour normaliser les choses, les consortiums ISO et Unicode ont présenté le Unicode . Unicode utilise deux octets pour stocker chaque caractère. Cela signifie que 65 536 caractères différents peuvent être définis, de sorte que presque tous les caractères peuvent être recouverts avec Unicode. Si deux ordinateurs utilisent Unicode, chaque symbole sera représenté de la même manière et aucune conversion n’est nécessaire - c’est l’idée qui sous-tend Unicode.

SQL Server a deux catégories de types de données de caractères:

non-Unicode (car, varchar et text)
Unicode (nchar, nvarchar et ntext)

Si nous devons sauvegarder des données de caractères de plusieurs pays, utilisez toujours Unicode.

Bien que NVARCHAR stocke Unicode, vous devez envisager de le classer. Vous pouvez également utiliser VARCHAR et enregistrer vos données dans les langues locales.

Imaginez le scénario suivant.

Le classement de votre base de données est en persan et vous enregistrez une valeur telle que "???" (écriture perse de Ali) dans le type de données VARCHAR (10) . Il n'y a pas de problème et le SGBD utilise seulement trois octets pour le stocker.

Toutefois, si vous souhaitez transférer vos données vers une autre base de données et voir le résultat correct, votre base de données de destination doit avoir le même classement que la cible, qui est Persian dans cet exemple.

Si votre classement cible est différent, des points d'interrogation (?) apparaissent dans la base de données cible.

Enfin, rappelez-vous que si vous utilisez une énorme base de données destinée à l’utilisation de votre langue locale, je vous recommanderais d’utiliser un lieu plutôt que d’utiliser trop d’espaces.

Je pense que le design peut être différent. Cela dépend de l'environnement sur lequel vous travaillez.

Je dois dire ici (je réalise que je vais probablement m'ouvrir à un slating!), mais le seul moment où NVARCHAR est en réalité plus utile (remarquez plus plus!) que VARCHAR lorsque tous les classements de tous les systèmes dépendants et de la base de données sont identiques ...? Sinon, la conversion de classement doit quand même avoir lieu et rend VARCHAR tout aussi viable que NVARCHAR .

Pour ajouter à cela, certains systèmes de base de données, tels que SQL Server (avant 2012) ont une taille de page d'env. 8K. Donc, si vous souhaitez stocker des données interrogeables non contenues dans un champ TEXT ou NTEXT , VARCHAR fournit la totalité des 8k de espace alors que NVARCHAR ne fournit que 4 ko (le double d'octets, le double d'espace).

Je suppose que, pour résumer, l’utilisation de l’un ou de l’autre dépend:

Projet ou contexte
Infrastructure
Système de base de données

Suivez Différence entre Sql Server VARCHAR et Type de données NVARCHAR . Ici, vous pouvez voir de manière très descriptive.

En général, nvarchar stocke les données au format Unicode. Ainsi, si vous prévoyez de stocker des données multilingues (plusieurs langues) dans une colonne de données, vous avez besoin de la variante N.

J’ai jeté un œil aux réponses et beaucoup semblent recommander d’utiliser nvarchar sur varchar , car l’espace n’est plus un problème, il n’ya donc aucun inconvénient à l’activation. Unicode pour peu de stockage supplémentaire. Eh bien, ce n'est pas toujours vrai lorsque vous souhaitez appliquer un index sur votre colonne. SQL Server limite la taille du champ que vous pouvez indexer à 900 octets. Donc, si vous avez un varchar (900) , vous pouvez toujours l'indexer, mais pas varchar (901) . Avec nvarchar , le nombre de caractères est divisé par deux, vous pouvez donc indexer jusqu'à nvarchar (450) . Donc, si vous êtes sûr de ne pas avoir besoin de nvarchar , je vous déconseille de l'utiliser.

En général, dans les bases de données, je vous recommande de vous en tenir à la taille dont vous avez besoin, car vous pouvez toujours développer. Par exemple, un collègue au travail a déjà pensé qu'il n'y avait aucun mal à utiliser nvarchar (max) pour une colonne, car nous n'avons aucun problème de stockage. Plus tard, lorsque nous avons essayé d'appliquer un index sur cette colonne, SQL Server l'a rejeté. Si, toutefois, il commençait avec même varchar (5) , nous aurions simplement pu l'étendre ultérieurement à ce dont nous avions besoin sans un tel problème qui nécessiterait la création d'un plan de migration de champ pour résoudre ce problème.

La principale différence entre Varchar (n) et nvarchar (n) est la suivante:

La taille

Varchar (données de caractères de longueur variable, non-Unicode) va jusqu'à 8000. 1.Il s'agit d'un type de données de longueur variable

Utilisé pour stocker des caractères non-Unicode
Occupe 1 octet d'espace pour chaque caractère

Nvarchar : Données de caractère Unicode de longueur variable.

1.Il s'agit d'un type de données de longueur variable

2.Utilisé pour stocker des caractères Unicode.

Les données sont stockées dans un codage Unicode. Chaque la langue est prise en charge. (par exemple les langues arabe, allemande, hindi, etc.)

Jeffrey L Whitledge avec ~ 47 000 points de réputation recommande l’utilisation de nvarchar

Solomon Rutzky avec ~ 33200 points de réputation recommande: N'utilisez PAS toujours NVARCHAR. C’est une attitude très dangereuse et souvent coûteuse.

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

https://www.sqlservercentral.com/articles/disk -is-pas-cher-orly-4

Les deux personnes d’une telle réputation, que choisit un développeur de bases de données apprenant serveur SQL?

Il existe de nombreux avertissements dans les réponses et les commentaires concernant les problèmes de performances si vous n'êtes pas cohérent dans vos choix.

Il y a des commentaires pro / con nvarchar pour la performance.

Il y a des commentaires pro / con varchar for performance.

J'ai un besoin particulier pour un tableau avec plusieurs centaines de colonnes, ce qui en soi est probablement inhabituel?

Je choisis varchar pour éviter de rester proche de la limite de taille d'enregistrement de la table de 8060 octets de SQL * Server 2012.

Pour moi, l'utilisation de nvarchar dépasse cette limite de 8060 octets.

Je pense également que je devrais faire correspondre les types de données des tables de codes connexes aux types de données de la table centrale principale.

J'ai vu l'utilisation de la colonne varchar sur ce lieu de travail, dans le sud de l'Australie, par des développeurs de bases de données expérimentés, où le nombre de lignes de la table sera de plusieurs millions ou plus (et très peu de colonnes nvarchar, le cas échéant, dans ces très grandes tables), alors peut-être que les volumes de lignes de données attendus feront partie de cette décision.

nvarchar est sûr à utiliser par rapport à varchar afin de rendre notre code exempt d'erreur (incompatibilité type) car nvarchar autorise également les caractères unicode . Lorsque nous utilisons la condition où dans une requête SQL Server et si nous utilisons l'opérateur = , une erreur est parfois générée. La raison probable en est que notre colonne de mappage sera définie dans varchar . Si nous l’avons défini dans nvarchar , ce problème ne se produira pas. Néanmoins, nous nous en tenons à varchar et pour éviter ce problème, nous ferions mieux d'utiliser le mot clé LIKE plutôt que = .

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow