Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
803 connectés 

  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  colonne défini comme clef primaire et clef étrangère, possible ??

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

colonne défini comme clef primaire et clef étrangère, possible ??

n°950980
weblook$$
Posté le 11-01-2005 à 17:35:40  profilanswer
 

salut,
 
j'aurais voulu savoir si il était possible sous Oracle 9i, de définir une colonne appartenant à une table comme étant clef Primaire de cette même table et également clef étrangère sur une autre table?
 
 
merci

mood
Publicité
Posté le 11-01-2005 à 17:35:40  profilanswer
 

n°950996
Arjuna
Aircraft Ident.: F-MBSD
Posté le 11-01-2005 à 18:04:51  profilanswer
 

Normalement, oui. D'un point de vue fonctionnel, je ne vois pas de raison de l'interdire :)
 
C'est une relation de type 0,1 -- 1,1 ce qui conceptuellement est tout à fait possible, bien que généralement déconseillé.

n°951000
Arjuna
Aircraft Ident.: F-MBSD
Posté le 11-01-2005 à 18:11:15  profilanswer
 

Avec SQL Server par exemple, je viens de créer une telle relation, et voici l'extract du script SQL de génération (c'est presque comme avec Oracle)
 

Code :
  1. CREATE TABLE [dbo].[subtree] (
  2. [id] [numeric](18, 0) NOT NULL ,
  3. [nom] [varchar] (50) COLLATE French_CI_AS NOT NULL
  4. ) ON [PRIMARY]
  5. GO
  6. CREATE TABLE [dbo].[tree] (
  7. [id] [numeric](18, 0) IDENTITY (1, 1) NOT NULL ,
  8. [nom] [varchar] (50) COLLATE French_CI_AS NOT NULL ,
  9. [parent] [numeric](18, 0) NULL
  10. ) ON [PRIMARY]
  11. GO
  12. ALTER TABLE [dbo].[subtree] WITH NOCHECK ADD
  13. CONSTRAINT [PK_subtree] PRIMARY KEY  CLUSTERED
  14. (
  15.  [id]
  16. )  ON [PRIMARY]
  17. GO
  18. ALTER TABLE [dbo].[tree] WITH NOCHECK ADD
  19. CONSTRAINT [PK_tree] PRIMARY KEY  CLUSTERED
  20. (
  21.  [id]
  22. )  ON [PRIMARY]
  23. GO
  24. ALTER TABLE [dbo].[subtree] ADD
  25. CONSTRAINT [FK_subtree_tree] FOREIGN KEY
  26. (
  27.  [id]
  28. ) REFERENCES [dbo].[tree] (
  29.  [id]
  30. )
  31. GO
  32. ALTER TABLE [dbo].[tree] ADD
  33. CONSTRAINT [FK_tree_tree] FOREIGN KEY
  34. (
  35.  [parent]
  36. ) REFERENCES [dbo].[tree] (
  37.  [id]
  38. )
  39. GO


 
(Voir "FK_subtree_tree" et "PK_subtree" )


Message édité par Arjuna le 11-01-2005 à 18:11:31
n°951001
weblook$$
Posté le 11-01-2005 à 18:11:39  profilanswer
 

nickel.
déconseillé , quel est le risque ?
si la clef étrangère référence une clef primaire, ça assure également l'unicité des données dans la table possédant la clef étrangère , non ?

n°951004
Arjuna
Aircraft Ident.: F-MBSD
Posté le 11-01-2005 à 18:12:42  profilanswer
 

=> Je ne pourrai mettre dans "SUBTREE" que des ID existant dans "TREE", et à chaque fois, ils seront la clé primaire (donc pas de doublon possible)

n°951008
Arjuna
Aircraft Ident.: F-MBSD
Posté le 11-01-2005 à 18:17:18  profilanswer
 

weblook$$ a écrit :


déconseillé , quel est le risque ?


Aucun risque. C'est juste que généralement, c'est pour éviter d'avoir une unique table avec des champs souvent vides. Ca améliore la logique de stockage, mais pas celle d'interrogation, et les requêtes sont allourdies inutilement. Mais ce n'est pas gênant en soit.
 
Par exemple, imaginons que t'as une table "client", et tu sais qu'un client peu parfois avoir une et une seule voiture, mais pas toujours. A ce moment, soit tu crées une seconde table "voiture", avec ce type de clé, soit tu crées des champs nullable dans "client" pour stocker les infos de "voiture". Tout mettre dans une seule table sera bien plus simple pour écrire des requêtes du style "je veux tous les clients qui n'ont pas de voiture : "select * from client where voiture is null", alors que si t'as deux tables, tu pars tout de suite dans une requête bien plus complexe (et inifiment plus lente). Mais bon, ce n'est pas bloquant, dans certains cas, ça peut tout à fait être justifié.
 

weblook$$ a écrit :


si la clef étrangère référence une clef primaire, ça assure également l'unicité des données dans la table possédant la clef étrangère , non ?


Pas du tout. Rien ne t'empêche de tenter d'insérer un doublon dans la table fille. C'est le fait que la clé étrangère soit aussi une clé primaire qui garantie que tu n'auras jamais de doublons.

n°951019
weblook$$
Posté le 11-01-2005 à 18:23:39  profilanswer
 

oui pas mal le coup du champ nullable ,ça aura ça place ailleurs dans mon projet.
Pour faire des champs nullable tu fais comment ? c'est juste un champ qui n'a pas "not null"  (toujours sous oracle)

n°951066
Arjuna
Aircraft Ident.: F-MBSD
Posté le 11-01-2005 à 19:25:10  profilanswer
 

Exactement :)


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  SQL/NoSQL

  colonne défini comme clef primaire et clef étrangère, possible ??

 

Sujets relatifs
SWT et applet : possible ?Tester une clef dans la base de registre?
[IIS] .htaccess et .htpasswd possible sur un IIS ?Base MySQL exploitée a partir d'un autre HDD ? Possible ?
Colonne dynamique dans une requête [SQL Server 2000 - Transact SQL]supprimer une variable d'une variable, est-ce possible ?
[HTML] largeur de colonneconstructeur d'un type générique [Résolu : pas possible]
excel cellule colonne vbs bouclePerl : est il possible de lire un fichier sans le bloquer en écriture?
Plus de sujets relatifs à : colonne défini comme clef primaire et clef étrangère, possible ??


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR