Différence entre NVARCHAR dans Oracle et SQL Server?
Nous migrons certaines données du serveur SQL vers Oracle. Pour les colonnes définies comme NVARCHAR dans SQL Server, nous avons commencé à créer des colonnes NVARCHAR dans Oracle en pensant qu'elles sont similaires .. Mais il semble qu'elles ne le soient pas.
J'ai lu quelques articles sur stackoverflow et je veux confirmer mes conclusions.
Oracle VARCHAR2 prend déjà en charge unicode si le jeu de caractères de la base de données est par exemple AL32UTF8 (ce qui est vrai dans notre cas).
SQLServer VARCHARne le fait pas supporte unicode. SQLServer requiert explicitement que les colonnes soient dans NCHAR/NVARCHAR type pour stocker les données en unicode (en particulier au format UCS-2 à 2 octets).
Par conséquent, serait-il exact de dire que les colonnes SQL Server NVARCHAR peuvent/doivent être migrées en tant que colonnes Oracle VARCHAR2?
Oui, si votre base de données Oracle est créée à l'aide d'un jeu de caractères Unicode, un NVARCHAR dans SQL Server doit être migré vers un VARCHAR2 Dans Oracle. Dans Oracle, le type de données NVARCHAR existe pour permettre aux applications de stocker des données à l'aide d'un jeu de caractères Unicode lorsque le jeu de caractères de la base de données ne prend pas en charge Unicode.
Cependant, une chose à prendre en compte lors de la migration est la sémantique de la longueur des caractères. Dans SQL Server, une NVARCHAR(20) alloue de l'espace pour 20 caractères, ce qui nécessite jusqu'à 40 octets dans UCS-2. Dans Oracle, par défaut, une VARCHAR2(20) alloue 20 octets de stockage. Dans le jeu de caractères AL32UTF8, Cela ne représente potentiellement que suffisamment d’espace pour 6 caractères, mais il gérera probablement beaucoup plus (un seul caractère dans AL32UTF8 Nécessite entre 1 et 3 octets. Vous voudrez probablement déclarez vos types Oracle comme VARCHAR2(20 CHAR) ce qui indique que vous souhaitez allouer de l'espace pour 20 caractères, quel que soit le nombre d'octets requis. Cela a tendance à être beaucoup plus facile à communiquer qu'à essayer d'expliquer pourquoi certaines chaînes de 20 caractères sont autorisées tandis que les 10 autres chaînes de caractères sont rejetées.
Vous pouvez modifier la sémantique de longueur par défaut au niveau de la session afin que toutes les tables que vous créez sans spécifier de sémantique de longueur utilisent des sémantiques plutôt que des octets.
ALTER SESSION SET nls_length_semantics=CHAR;
Cela vous permet d'éviter de taper CHAR chaque fois que vous définissez une nouvelle colonne. Il est également possible de définir cela au niveau du système, mais cela est déconseillé par l'équipe NLS - apparemment, tous les scripts fournis par Oracle n'ont pas été minutieusement testés par rapport aux bases de données où le NLS_LENGTH_SEMANTICS A été modifié. Et probablement très peu de scripts tiers l'ont été.