Si vous avez un choix proche, utilisez un jeu de caractères Unicode pour l'ensemble de la base de données. La vie en général est simplement aveuglément plus facile de cette façon.
- Il existe de nombreux utilitaires et bibliothèques tiers qui ne prennent tout simplement pas en charge les colonnes NCHAR/ NVARCHAR2 ou qui ne rendent pas agréable le travail avec les colonnes NCHAR/ NVARCHAR2. C'est extrêmement ennuyeux, par exemple, lorsque votre nouvel outil de création de rapports ne peut pas générer de rapport sur vos données NVARCHAR2.
- Pour les applications personnalisées, l'utilisation de colonnes NCHAR/ NVARCHAR2 nécessite de franchir certaines étapes, contrairement à l'utilisation de colonnes codées Unicode CHAR/ VARCHAR2. Dans le code JDBC, par exemple, vous appelleriez constamment la méthode Statement.setFormOfUse. D'autres langages et frameworks auront d'autres pièges; certains seront relativement bien documentés et d'autres mineurs seront relativement obscurs.
- De nombreux packages intégrés n'acceptent (ou ne renvoient) qu'un VARCHAR2 plutôt qu'un NVARCHAR2. Vous pourrez toujours les appeler en raison de la conversion implicite, mais vous risquez de rencontrer des problèmes de conversion de jeu de caractères.
- En général, le fait de pouvoir éviter les problèmes de conversion de jeux de caractères au sein de la base de données et de reléguer ces problèmes à la périphérie, là où la base de données envoie ou reçoit réellement des données d'un client, facilite grandement le développement d'une application. C'est assez de travail pour déboguer les problèmes de conversion de jeu de caractères qui résultent de la transmission réseau - comprendre que certaines données ont été corrompues lorsqu'une procédure stockée a concaténé les données d'un VARCHAR2 et d'un NVARCHAR2 et stocké le résultat dans un VARCHAR2 avant qu'il ne soit envoyé sur le réseau peut être atroce.
Oracle a conçu les types de données NCHAR/NVARCHAR2 pour les cas où vous essayez de prendre en charge des applications héritées qui ne prennent pas en charge Unicode dans la même base de données que les nouvelles applications qui utilisent Unicode et pour les cas où il est avantageux de stocker certaines données Unicode avec un autre encodage (c'est-à-dire que vous avez une grande quantité de données japonaises que vous préféreriez stocker en utilisant l'encodage UTF-16 dans un NVARCHAR2 plutôt que l'encodage UTF-8). Si vous n'êtes pas dans l'une de ces deux situations, et que cela ne semble pas être le cas, j'éviterais NCHAR/ NVARCHAR2 à tout prix.
Répondre à vos relances
Notre application est généralement seule sur la base de données Oracle et s'occupe elle-même des données. Les autres logiciels qui se connectent à la base de données sont limités à Toad, Tora ou développeur SQL.
Que voulez-vous dire par "s'occupe des données elles-mêmes" ? J'espère que vous ne dites pas que vous avez configuré votre application pour contourner les routines de conversion des jeux de caractères d'Oracle et que vous effectuez vous-même toute la conversion des jeux de caractères.
Je suppose également que vous utilisez une sorte d'API/bibliothèque pour accéder à la base de données même s'il s'agit d'OCI. Avez-vous examiné les modifications que vous devrez apporter à votre application pour prendre en charge NCHAR/ NVARCHAR2 et si l'API que vous utilisez prend en charge NCHAR/ NVARCHAR2 ? Le fait que vous obteniez des données Unicode en C++ n'indique pas réellement que vous n'aurez pas besoin d'apporter des modifications (potentiellement importantes) pour prendre en charge les colonnes NCHAR/NVARCHAR2.
Nous utilisons également SQL*Loader et SQL*Plus pour communiquer avec la base de données pour les instructions de base ou pour mettre à niveau entre les versions du produit. Nous n'avons entendu aucun problème spécifique avec tous ces logiciels concernant NVARCHAR2.
Ces applications fonctionnent toutes avec NCHAR/NVARCHAR2. NCHAR/ NVARCHAR2 introduisent des complexités supplémentaires dans les scripts, en particulier si vous essayez d'encoder des constantes de chaîne qui ne sont pas représentables dans le jeu de caractères de la base de données. Cependant, vous pouvez certainement contourner les problèmes.
Nous ne savons pas non plus que les administrateurs de base de données parmi nos clients aimeraient utiliser d'autres outils sur la base de données qui ne pourraient pas prendre en charge les données sur NVARCHAR2 et nous ne nous soucions pas vraiment de savoir si leurs outils pourraient perturber, après tout, ils sont qualifiés dans leur travail et peuvent trouver d'autres outils si nécessaire.
Bien que je sois sûr que vos clients peuvent trouver d'autres façons de travailler avec vos données, si votre application ne fonctionne pas bien avec leur outil de création de rapports d'entreprise ou leur outil ETL d'entreprise ou tout autre outil de bureau avec lequel ils sont expérimentés, il est très probable que le client blâmera votre application plutôt que ses outils. Ce ne sera probablement pas un bouchon de spectacle, mais il n'y a également aucun avantage à causer inutilement du chagrin aux clients. Cela ne les incitera peut-être pas à utiliser le produit d'un concurrent, mais cela ne les incitera pas à adopter votre produit.
Pourrions-nous également nous attendre à une rupture de performances si notre application (qui est compilée sous Visual C++), qui utilise wchar_t pour stocker UTF-16, doit effectuer des conversions d'encodage sur toutes les données traitées ?
Je ne sais pas de quelles "conversions" vous parlez. Cela peut revenir à ma question initiale de savoir si vous déclarez que vous contournez la couche NLS d'Oracle pour effectuer vous-même la conversion du jeu de caractères.
Ma conclusion, cependant, est que je ne vois aucun avantage à utiliser NCHAR/NVARCHAR2 compte tenu de ce que vous décrivez. Il y a beaucoup d'inconvénients potentiels à les utiliser. Même si vous pouvez éliminer 99% des inconvénients comme non pertinents pour vos besoins particuliers, vous êtes toujours confronté à une situation où, au mieux, il s'agit d'un lavage entre les deux approches. Compte tenu de cela, je préférerais de loin l'approche qui maximise la flexibilité à l'avenir, et qui convertit l'intégralité de la base de données en Unicode (AL32UTF8 vraisemblablement) et l'utilise simplement.
