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

Marsh Posté le 11-01-2005 à 17:35:40

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

Reply

Marsh Posté le 11-01-2005 à 17:35:40

Reply

Marsh Posté le 11-01-2005 à 18:04:51

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é.

Reply

Marsh Posté le 11-01-2005 à 18:11:15

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 :

CREATE TABLE [dbo].[subtree] (
[id] [numeric](18, 0) NOT NULL ,
[nom] [varchar] (50) COLLATE French_CI_AS NOT NULL
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[tree] (
[id] [numeric](18, 0) IDENTITY (1, 1) NOT NULL ,
[nom] [varchar] (50) COLLATE French_CI_AS NOT NULL ,
[parent] [numeric](18, 0) NULL
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[subtree] WITH NOCHECK ADD
CONSTRAINT [PK_subtree] PRIMARY KEY CLUSTERED
(
[id]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[tree] WITH NOCHECK ADD
CONSTRAINT [PK_tree] PRIMARY KEY CLUSTERED
(
[id]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[subtree] ADD
CONSTRAINT [FK_subtree_tree] FOREIGN KEY
(
[id]
) REFERENCES [dbo].[tree] (
[id]
)
GO
ALTER TABLE [dbo].[tree] ADD
CONSTRAINT [FK_tree_tree] FOREIGN KEY
(
[parent]
) REFERENCES [dbo].[tree] (
[id]
)
GO

(Voir "FK_subtree_tree" et "PK_subtree" )

Message édité par Arjuna le 11-01-2005 à 18:11:31

Reply

Marsh Posté le 11-01-2005 à 18:11:39

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 ?

Reply

Marsh Posté le 11-01-2005 à 18:12:42

=> 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)

Reply

Marsh Posté le 11-01-2005 à 18:17:18

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.

Reply

Marsh Posté le 11-01-2005 à 18:23:39

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)

Reply

Marsh Posté le 11-01-2005 à 19:25:10

Exactement

Reply

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

Sujets relatifs:

Leave a Replay