Définition d'un jeu de caractères pour une colonne Pour les tables de base de données Oracle

Je suis en cours d'exécution de requêtes suivantes en SQL*Plus

CREATE TABLE  tbl_audit_trail (
  id NUMBER(11) NOT NULL,
  old_value varchar2(255) NOT NULL,
  new_value varchar2(255) NOT NULL,
  action varchar2(20) CHARACTER SET latin1 NOT NULL,
  model varchar2(255) CHARACTER SET latin1 NOT NULL,
  field varchar2(64) CHARACTER SET latin1 NOT NULL,
  stamp timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  user_id NUMBER(11) NOT NULL,
  model_id varchar2(65) CHARACTER SET latin1 NOT NULL,
  PRIMARY KEY (id),  
  KEY idx_action (action)
);

J'obtiens l'erreur suivante:

action varchar2(20) CHARACTER SET latin1 NOT NULL,
                      *
ERROR at line 5:
ORA-00907: missing right parenthesis

Pouvez-vous suggérer ce qui me manque?

source d'informationauteur Ashwin N Bhanushali

29

La réponse simple est que, contrairement à MySQL, les jeux de caractères ne peut pas être défini à la colonne (ou la table) niveau. Latin1 n'est pas valide Oracle jeu de caractères.

Jeux de caractères sont cohérents dans la base de données et ont été spécifiés lors de la création de la base de données. Vous pouvez trouver votre personnage en interrogeant NLS_DATABASE_PARAMETERS
```
select value
  from nls_database_parameters
 where parameter = 'NLS_CHARACTERSET'
```
La liste exhaustive des jeux de caractères est disponible pour 11g r2 et pour 9i ou vous pouvez interroger V$NLS_VALID_VALUES.

Il est possible d'utiliser le ALTER SESSION déclaration pour définir la NLS_LANGUAGE ou la NLS_TERRITORYmais malheureusement, vous ne pouvez pas le faire pour le jeu de caractères. Je crois que c'est parce que modifier la langue qui change la façon dont Oracle affichage les données stockées considérant que la modification du jeu de caractères allait changer la façon dont Oracle magasins les données.

Lors de l'affichage des données, vous pouvez spécifier le jeu de caractères requis quel que soit le client que vous utilisez.

Jeu de caractères de la migration n'est pas une tâche facile et ne doit pas être fait à la légère.

Sur une légère note de côté, pourquoi essayez-vous d'utiliser le Latin 1? Il serait plus normal pour configurer une nouvelle base de données en quelque chose comme de l'UTF-8 (autrement connu comme AL32UTF8 - ne pas utiliser de UTF8) ou UTF-16, de sorte que vous pouvez stocker multi-octets des données de manière efficace. Même si vous n'en avez pas besoin maintenant, c'est sage d'essayer - pas de garanties dans la vie, l'avenir de votre base de données sans avoir besoin de migrer dans l'avenir.

Si vous êtes à la recherche pour spécifier les différents jeux de caractères pour les différentes colonnes dans une base de données, alors la meilleure option serait de déterminer si cette exigence est vraiment nécessaire, et d'essayer de le supprimer. Si il est certainement nécessaire¹alors votre meilleur pari pourrait être d'utiliser un jeu de caractères qui est un sur-ensemble de tous les ensembles de caractères. Ensuite, avoir une sorte de vérification de la contrainte qui limite la colonne spécifique de valeurs hexadécimales. Je ne recommande pas de le faire lors de tous, le potentiel pour des erreurs de fluage en est massif et il est extrêmement complexe. En outre, les différents jeux de caractères à afficher différentes valeurs hexadécimales différemment. Ceci, à son tour, signifie que vous devez appliquer qu'une colonne est rendu dans un caractère spécifique, ce qui est impossible, puisqu'elle se situe en dehors du champ de la base de données.

_{1. Je serais intéressé de connaître la situation}
4

Selon instruction DDL c'est le besoin d'utiliser 2 jeux de caractères. La mise en œuvre de cette fonctionnalité dans Oracle est différente de MySQL et fait avec n* types de données comme les nvarchar2, nchar... Latin1 est similaire à un jeu de caractères qui pourraient être en défaut. Si vous en mesure de définir par exemple "Latin1" (NOUS**) et certains Unicode (UTF8..).

La NVARCHAR2 type de données a été introduit par Oracle pour les bases de données qui souhaitent utiliser l'Unicode pour certaines colonnes, tout en conservant un autre jeu de caractères pour le reste de la base de données (qui utilise VARCHAR2). Le NVARCHAR2 est une Unicode uniquement type de données.
La raison pour laquelle vous souhaitez utiliser NVARCHAR2 peut-être que votre base de données utilise un caractère non-Unicode et vous voulez toujours être en mesure de stocker des données Unicode pour certaines colonnes.
Les colonnes dans votre exemple serait capable de stocker le même, mais dans l'octet de stockage sera différent.

Vous devez vous connecter pour publier un commentaire.