sont gérées dans PostgreSQL via des triggers.
Aussi les triggers sont utilisés lors de la suppression/update dans ta
table Foo et lors de l'insertion dans ta table Bar.
Cela voudrait ainsi dire que lorsque tu supprimes une entrée dans Foo,
le trigger doive vérifier la non-existence dans Bar ainsi que, si
existence il y a, la présence d'un doublon dans Foo autorisant la
suppression.
Techniquement c'est possible mais je pense que ça complexifie les
choses.
D'autre part, conceptuellement, cela revient à faire une relation une
relation n to n. Je ne sais pas si c'est très normal de cette façon là.
Quelqu'un sait si c'est possible sur d'autre base de données (genre
oracle, sql server)
Le contournement pour le coup est relativement simple. Il suffit juste
d'écrire des triggers équivalent à ce que fait PostgreSQL avec le test
tel que je l'ai décris en plus un peu plus haut. Regarde du côté des
contrib pour voir si ça n'existe pas déjà... Mais bon c'est plus des
références Postgresql dans ce cas là...
Voila...
Le Mon, 8 Sep 2008 16:56:35 +0200, Stephane
Bortzmeyer <bortzmeyer@nic.fr> a écrit :
> J'essaie de mettre une contrainte référentielle mais le champ visé n'a
> pas été déclaré comme UNIQUE :
>
> essais=> CREATE TABLE Foo(name TEXT NOT NULL);
> CREATE TABLE
> essais=> CREATE TABLE Bar(truc TEXT, machin TEXT REFERENCES
> Foo(name)); ERROR: there is no unique constraint matching given keys
> for referenced table "foo"
>
> [Si Foo(name) est déclaré UNIQUE, cela passe.]
>
> Première question : pourquoi PostgreSQL 8.3 impose t-il cette
> contrainte supplémentaire qui ne me semble pas logique ?
>
> Deuxième question : quel contournement utiliser à part abandonner la
> sécurité que me fournit REFERENCES ?
>
--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale
No comments:
Post a Comment