Clé étrangère et double contraintes

Clé étrangère et double contraintes - SQL/NoSQL - Programmation

Marsh Posté le 28-01-2005 à 13:00:14    

Bonjour,
 
   Je souhaiterais avoir une clé étrangère dans une table X qui dépendent d'un champ d'un table Y OU Z
 
 
   Voilà le code que j'ai utilisé qui impose que la clé étrangère appartienne aux DEUX tables. Or, je voudrais qu'elle puisse appartenir à l'une OU à l'autre. Est-ce possible et avez-vous une solution?
 
Merci de vos réponses par avance...
 

Code :
  1. CREATE TABLE Y(
  2.    ChampY INTEGER,
  3. );
  6. CREATE TABLE Z(
  7.    ChampZ INTEGER
  8. );
  11. CREATE TABLE X(
  12.    ChampX INTEGER,
  14.    CONSTRAINT fk_essai1 FOREIGN KEY (ChampX) REFERENCES Y(ChampY),
  15.    CONSTRAINT fk_essai2 FOREIGN KEY (ChampX) REFERENCES Z(ChampZ),
  16. );

Reply

Marsh Posté le 28-01-2005 à 13:00:14   

Reply

Marsh Posté le 28-01-2005 à 13:10:36    

Moi je dirais impossible mais sans garanties ...
T'utilises quel SGBD ?


Message édité par albataur le 28-01-2005 à 15:31:07
Reply

Marsh Posté le 28-01-2005 à 13:23:22    

PostgreSQL

Reply

Marsh Posté le 28-01-2005 à 13:30:50    

A ma connaissance, ce n'est pas possible (aussi sans garantie).
 
Tu peux passer par un trigger, qui garantira facilement cette contrainte d'intégrité.


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 28-01-2005 à 19:25:39    

c'est pas très logique ce type de problème ... c'est probablement lié à un mauvais design des 2 tables en question.

Reply

Marsh Posté le 28-01-2005 à 20:02:44    

Beegee a écrit :

c'est pas très logique ce type de problème ... c'est probablement lié à un mauvais design des 2 tables en question.


Je dirais la même chose.
 
Charlux> en fait tu devrais mettre une clé étrangère dans Table Y et l'autre dans Table Z. Là tu n'auras forcément plus de problèmes.
 
Ce qui donne:

Code :
  1. CREATE TABLE Y(
  2.    ChampY INTEGER,
  3.  
  4.    CONSTRAINT fk_essai1 FOREIGN KEY (ChampY) REFERENCES X(ChampX),
  5. );
  8. CREATE TABLE Z(
  9.    ChampZ INTEGER
  11.    CONSTRAINT fk_essai2 FOREIGN KEY (ChampZ) REFERENCES X(ChampX),
  12. );
  15. CREATE TABLE X(
  16.    ChampX INTEGER,
  17. );


Message édité par WhatDe le 28-01-2005 à 20:05:44
Reply

Marsh Posté le 28-01-2005 à 21:35:43    

Non, ce n'est pas forcément illogique.
 
Tu peux imaginer que X et Y représentent deux entités suffisamment différentes que pour constituer deux tables, car leurs attributs diffèrent, mais qu'elles ont qq chose en commun Z que tu ne veux pas recopier dans chacune des deux tables.
 
Je suis certain d'avoir eu le cas il y a un certain temps (un temps certain), et un sélecteur XOR s'était naturelement imposé.
 
Je dis pas, c'est pas hyper-fréquent et c'est un peu suspect a priori.
 
Charlux, que modélisent X, Y et Z stp ?


---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 28-01-2005 à 22:46:00    

Le qqch en commun devrait logiquement se trouver dans une table à part ... :)

Reply

Marsh Posté le 28-01-2005 à 23:06:39    

Beegee a écrit :

Le qqch en commun devrait logiquement se trouver dans une table à part ... :)


Beh oui, X en l'occurence (et non pas Z comme je l'ai dit plus haut; je m'emmêle les pinceaux avec ses lettres abstraites à cette heure-ci).
 
Enfin, s'il nous disait de quoi il retourne, on verrait bien. Et 95% de chances pour que ce ne soit pas le bon design, comme tu le dis.


Message édité par sircam le 28-01-2005 à 23:06:50

---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 29-01-2005 à 00:16:08    

Dans ce genre de cas, tu as 2 champs dans x, un pour y et un pour z, vu que y et z ne représentent pas la même chose.
 
Sinon, c'est qu'il faut mette y et z dans une seule et même table.


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 29-01-2005 à 00:16:08   

Reply

Marsh Posté le 29-01-2005 à 11:49:25    

Mara's dad a écrit :

Dans ce genre de cas, tu as 2 champs dans x, un pour y et un pour z, vu que y et z ne représentent pas la même chose.


*TILT* Le franc est tombé (heu l'euro).
 
Il propose un seul champs avec deux FK XOR, pas deux champs...  :heink: Y'avais pas vu, -1 pour moi.
 
Sorry, ça me paraissait tellement évident qu'il fallait 2 champs et ce truc a l'air tellement faux que je suis passé à côté!
 
Je me joins à vous. :jap:


Message édité par sircam le 29-01-2005 à 11:49:46

---------------
Now Playing: {SYNTAX ERROR AT LINE 1210}
Reply

Marsh Posté le 31-01-2005 à 16:36:21    

Tu peux essayer un truc idiot qui me vient à l'esprit. Je dirais qu'avec SQL Server 2000 et Oracle >= 9i y'a des chances que ça marche :
 

Code :
  1. CREATE TABLE Y(
  2.    ChampY INTEGER,
  3. );
  5. CREATE TABLE Z(
  6.    ChampZ INTEGER
  7. );
  9. CREATE VIEW MONTRUCDEBILE(
  10.    ChampRef INTEGER)
  11. AS
  12. SELECT ChampY ChampRef FROM Y
  13. UNION
  14. SELECT ChampZ ChampRef FROM Z;
  16. CREATE TABLE X(
  17.    ChampX INTEGER,
  19.    CONSTRAINT fk_essaidebile FOREIGN KEY (ChampX) REFERENCES MONTRUCDEBILE(ChampRef)
  20. );


 
Mais logiquement, une clé externe ne peut porter que sur une table et non pas une vue. Dans tous les cas, si ton SGBD le supporte, il faudra lui expliciter que c'est sur une vue que porte la référence, et non pas une table.

Reply

Marsh Posté le 31-01-2005 à 16:38:43    

En extrapolant sur la doc de SQL Server 2000, tu peux peut-être aussi tenter ça :
 

Code :
  1. CREATE TABLE cust_sample
  2.     (
  3.     cust_id                int        PRIMARY KEY,
  4.     cust_name            char(50),
  5.     cust_address            char(50),
  6.     cust_credit_limit    money,
  7.     CONSTRAINT chk_id CHECK (cust_id in (select champY val from Y UNION select champZ val from Z)
  8.     )

Reply

Marsh Posté le 31-01-2005 à 16:43:22    

D'après la doc de SQL Server 2000, ça semble rappé pour la contrainte CHECK qui utilise une autre table (select) :
 

Citation :


Contraintes CHECK
Une colonne peut posséder un nombre illimité de contraintes CHECK et la condition peut inclure plusieurs expressions logiques combinées par AND et OR. S'il existe plusieurs contraintes CHECK pour une même colonne, elles sont validées dans l'ordre de leur création.
 
 
La condition de recherche doit correspondre à une expression booléenne et ne peut pas faire référence à une autre table.
 
 
Une contrainte CHECK de niveau colonne ne peut faire référence qu'à la colonne contenant la contrainte, et une contrainte CHECK de niveau table ne peut faire référence qu'aux colonnes d'une même table.  
Les contraintes CHECK et les règles servent toutes les deux à valider les données lors des instructions INSERT et DELETE.
 
Quand il existe une règle et une ou plusieurs contraintes CHECK pour une colonne, toutes les restrictions sont évaluées.  


 
T'as plus qu'à faire un trigger je pense :D
 
 
 
Pas contre, la FK sur une vue, rien n'est spécifié dans l'aide. Même si le mot "table" est utilisé tous les deux mots, jamais il est spécifié qu'il faut que ce soit obligatoirement une table :D A tester donc ;)


Message édité par Arjuna le 31-01-2005 à 16:46:11
Reply

Sujets relatifs:

Leave a Replay

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