oracle foreign key

oracle foreign key - SQL/NoSQL - Programmation

Marsh Posté le 29-09-2010 à 14:49:13    

J'essaie :
ALTER TABLE TREGLT
ADD CONSTRAINT CD_BUR_PAYEUR_FK
  FOREIGN KEY (CD_BUR_PAYEUR)
  REFERENCES TBUR_PAYEUR (CD_BUR_PAYEUR);
 
ORA-02270: pas de correspondance de clé primaire ou unique pour cette liste de colonnes  :??:  
 
et j'ai en base
 
CREATE TABLE TBUR_PAYEUR
(
  TBUR_PAYEUR_ID  NUMBER(11),
  CD_BUR_PAYEUR   VARCHAR2(8 BYTE)    
  LIB_AERO        VARCHAR2(64 BYTE)      
  LIB_APPLI       VARCHAR2(64 BYTE)  
  TIME_STAMP      DATE            
)
 
CREATE UNIQUE INDEX IDX_CD_BUR_PAYEUR ON TBUR_PAYEUR
(CD_BUR_PAYEUR)
 
CREATE UNIQUE INDEX TBUR_PAYEUR_PK ON TBUR_PAYEUR
(TBUR_PAYEUR_ID)
 
ALTER TABLE TBUR_PAYEUR ADD (
  CONSTRAINT TBUR_PAYEUR_PK
 PRIMARY KEY
 (TBUR_PAYEUR_ID)
 
 
 

Reply

Marsh Posté le 29-09-2010 à 14:49:13   

Reply

Marsh Posté le 29-09-2010 à 14:55:08    

euh... oui, et?

Reply

Marsh Posté le 29-09-2010 à 15:24:46    

"pas de correspondance de clé primaire ou unique pour cette liste de colonnes"' pourtant CREATE UNIQUE INDEX IDX_CD_BUR_PAYEUR ON TBUR_PAYEUR
(CD_BUR_PAYEUR)  
c'est bien une clé unique non???

Reply

Marsh Posté le 29-09-2010 à 16:18:44    

ben sauf si j'me goure, non c'est un index... :spamafote:

Reply

Marsh Posté le 29-09-2010 à 16:21:29    

Est-ce que la table TREGLT  contient bien un champ nommé CD_BUR_PAYEUR ?
Est-ce qu'il ne manque pas des virgules et des point virgules dans le code de création de la table TBUR_PAYEUR  ?
 
De toutes façons, le problème est que la clé étrangère n'est pas une clé primaire.
Voir http://www.techonthenet.com/oracle/errors/ora02270.php
En plus, cela ne respecte pas les règles de normalisation.
 
N.B. Au lieu de créer des contraintes dans la base, il vaut mieux mettre des contrôles dans les programmes d'insertion ou de mise à jour de données. Cela présente deux avantages :
- Le message d'erreur est affiché au bon endroit par le programme de contrôle, sous la bonne forme, avec une suite logique, au lieu de faire planter le programme.
- On peut charger des données en masse qui, d'une manière temporaire, ne sont pas cohérentes sans que cela ne soit bloquant. Charger des données en masse est souvent utile pour une initialisation de base, pour une récupération d'une sauvegarde, ou pour des tests.
 
 
 
 
 

Reply

Marsh Posté le 29-09-2010 à 16:57:49    

Justement moi je dis l'inverse : une contrainte gérée par la base sera mieux faite par la base elle-même
Pour l'insertion en masse il y a des utilitaires fournis pour ca (notamment sqlldr) et les ETL s'appuient également la-dessus. Il suffit de jouer avec les options pour régler le curseur entre la verbosité et les performances

Reply

Marsh Posté le 29-09-2010 à 17:16:56    

olivthill a écrit :

N.B. Au lieu de créer des contraintes dans la base, il vaut mieux mettre des contrôles dans les programmes d'insertion ou de mise à jour de données.


Ah ben oui bonne idée, comme ça au moindre bug dans ton programme qui passe en prod' sans le voir tu risques de perdre la cohérence des données.[:dawak]
Au-secours.[:pingouino]


---------------
Can't buy what I want because it's free -
Reply

Marsh Posté le 30-09-2010 à 09:45:11    

oui merci de votre aide d'accord c'est un index et l'erreur est bien "clé", il faut ajouter une constrainte
ALTER TABLE GESTION_DB.tbur_payeur ADD CONSTRAINT unique_cd_bur_payeur UNIQUE (cd_bur_payeur)
(cd_bur_payeur est bien dans la table tbur_payeur.)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed