Est-ce juste que nvarchar prend en charge les caractères multioctets? Si tel est le cas, y a-t-il vraiment un intérêt, en dehors des préoccupations de stockage, à utiliser des varchars?
Une colonne nvarchar peut stocker n'importe quelles données Unicode. Une colonne varchar est limitée à une page de code sur 8 bits. Certaines personnes pensent que varchar devrait être utilisé car il prend moins de place. Je crois que ce n'est pas la réponse correcte. Les incompatibilités de pages de code sont pénibles, et Unicode est le remède aux problèmes de page de code. Avec des disques et de la mémoire bon marché de nos jours, il n'y a vraiment aucune raison de perdre du temps à jongler avec les pages de code.
Tous les systèmes d'exploitation modernes et plates-formes de développement utilisent Unicode en interne. En utilisant nvarchar plutôt que varchar, vous pouvez éviter de faire des conversions d'encodage à chaque lecture ou écriture dans la base de données. Les conversions prennent du temps et sont sujettes aux erreurs. Et récupérer des erreurs de conversion est un problème non trivial.
Si vous communiquez avec une application qui utilise uniquement de l'ASCII, je recommanderais quand même d'utiliser Unicode dans la base de données. Les algorithmes de collation du système d'exploitation et de la base de données fonctionneront mieux avec Unicode. Unicode évite les problèmes de conversion lors de l'interface avec d'autres systèmes. Et vous vous préparerez pour l'avenir. Vous pouvez toujours valider que vos données sont limitées à de l'ASCII sur 7 bits pour tout système hérité que vous êtes obligé de maintenir, tout en bénéficiant des avantages d'un stockage complet en Unicode.
C'est une super info à avoir. Donc, est-ce que je comprends correctement si je déduis que le choix devient finalement celui de - quelle ressource est moins chère: le processeur + les frais de développement ou le stockage?
@MatthewPatrickCashatt - Vous pourriez le voir de cette façon. Mais si vous imaginez un monde glorieux dans lequel toutes les données textuelles sont en Unicode, et que les développeurs n'ont tout simplement jamais à se soucier de l'encodage de quelque chose, et qu'une série d'erreurs ne se produisent tout simplement jamais, alors vous pouvez voir qu'il n'y a vraiment aucun choix.
varchar: Données de caractères non Unicode de longueur variable. La collation de la base de données détermine la page de code dans laquelle les données sont stockées.
nvarchar: Données de caractères Unicode de longueur variable. Dépendant de la collation de la base de données pour les comparaisons.
Armé de ces connaissances, utilisez celui qui correspond à vos données d'entrée (ASCII v. Unicode).
Est-ce qu'il y a une restriction comme quoi varchar ne peut pas stocker des données Unicode ? Ce ne sont que des 1 et des 0. Je suis capable de sauvegarder du contenu chinois en tant que varchar sans problème dans ma base de données. Je spécifie simplement qu'il s'agit d'UTF-8. Comment est-ce que cela fonctionne alors ?
@Nishant tardive réponse: bien sûr, vous pouvez stocker de l'UTF-8 dans varchar mais cela va casser les fonctions de chaîne SQL Server. Si vous effectuez toutes les recherches/transformatons dans votre application alors oui, vous pouvez le faire (mais quel en est le bénéfice?). Le seul encodage Unicode pris en charge par SS est UCS-2 (oui, pas UTF-16 avant SS2k16) et ses fonctions de chaîne fonctionnent seulement avec cet encodage. Au fait, qu'en est-il des indices? Si vous voulez stocker des données arbitraires, vous feriez mieux d'utiliser du binaire à la place.
Je n'utilise toujours nvarchar car il permet à tout ce que je construis de supporter à peu près n'importe quelle donnée que je lui transmets. Mon système de gestion de contenu prend en charge le chinois par accident, car j'ai utilisé nvarchar. De nos jours, les nouvelles applications ne devraient pas vraiment se soucier de la quantité d'espace requise.
L'idée selon laquelle les nouvelles applications ne devraient pas se soucier des restrictions d'espace est quelque peu courte vue, et toute personne ayant affaire aux bases de données au niveau des entreprises de taille moyenne à grande se fera un plaisir de vous dire, complètement incorrecte.
Pour me permettre de mettre des mots dans la bouche de tags2k, je pense qu'une déclaration plus précise serait peut-être : "il est de plus en plus improbable que de nouvelles applications devraient se soucier davantage de l'espace nécessaire que de l'internationalisation et d'autres problèmes liés à l'ensemble de caractères".
Ces jours-ci, toute nouvelle application ne devrait vraiment pas se soucier de la quantité d'espace requise. - À moins que vous n'utilisiez un stockage cloud gratuit, où le plan payant représente un bond CONSIDÉRABLE en $ (voir les plans partagés de SQL Server d'AppHarbor).
Cela dépend de la manière dont Oracle a été installé. Pendant le processus d'installation, l'option NLS_CHARACTERSET est définie. Vous pouvez peut-être la trouver avec la requête SÉLECTIONNER value$ DE sys.props$ OÙ nom = 'NLS_CHARACTERSET'.
Si votre NLS_CHARACTERSET est un encodage Unicode comme UTF8, génial. Utiliser VARCHAR et NVARCHAR est pratiquement identique. Arrêtez de lire maintenant, foncez. Sinon, ou si vous n'avez aucun contrôle sur l'ensemble de caractères Oracle, continuez à lire.
VARCHAR — Les données sont stockées dans l'encodage NLS_CHARACTERSET. Si d'autres instances de base de données sont sur le même serveur, vous pouvez être limité par elles ; et vice versa, puisque vous devez partager le paramètre. Un champ de ce type peut stocker toutes les données pouvant être encodées avec cet ensemble de caractères, et rien d'autre. Donc, par exemple si l'ensemble de caractères est MS-1252, vous ne pouvez stocker que des caractères comme des lettres anglaises, quelques lettres accentuées, et quelques autres (comme € et —). Votre application ne serait utile qu'à quelques régions, incapable de fonctionner ailleurs dans le monde. Pour cette raison, c'est considéré comme une mauvaise idée.
NVARCHAR — Les données sont stockées dans un codage Unicode. Toutes les langues sont prises en charge. Une bonne idée.
Qu'en est-il de l'espace de stockage ? VARCHAR est généralement efficace, car l'ensemble de caractères/l'encodage a été conçu sur mesure pour une région spécifique. Les champs NVARCHAR stockent soit en encodage UTF-8 soit en UTF-16, basé sur le paramètre NLS ironiquement. UTF-8 est très efficient pour les langues "occidentales", tout en prenant en charge les langues asiatiques. UTF-16 est très efficace pour les langues asiatiques, tout en prenant en charge les langues "occidentales". Si vous vous souciez de l'espace de stockage, choisissez un paramètre NLS pour que Oracle utilise UTF-8 ou UTF-16 selon ce qui est approprié.
Et concernant la vitesse de traitement ? La plupart des nouvelles plateformes de codage utilisent Unicode de manière native (Java, .NET, même std::wstring en C++ il y a des années !) donc si le champ de base de données est VARCHAR, cela oblige Oracle à convertir entre les ensembles de caractères à chaque lecture ou écriture, pas si bon. Utiliser NVARCHAR évite la conversion.
En conclusion : Utilisez NVARCHAR ! Cela évite les limitations et dépendances, est adéquat en termes d'espace de stockage, et généralement le meilleur pour la performance également.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
6 votes
J'aime le point d'incomudro, c'est ce qui m'a amené à creuser la différence entre varchar & nvarchar en premier lieu. Notre application Java sur une base de données SQL Server utilise myBatis, qui semble envoyer des chaînes de caractères en nvarchar par défaut (je ne suis toujours pas sûr si c'est modifiable). Une requête simple posait un énorme problème de performances car j'avais défini la colonne sur laquelle elle sélectionne en tant que varchar, pas nvarchar, et elle ignorait l'index sur la colonne.