Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur Est il conseillé de mettre des contraintes FOREIGN KEY ?

Est il conseillé de mettre des contraintes FOREIGN KEY ?

11 réponses
Avatar
Gilles TOURREAU
Salut tout le monde !

J'ai une base de donnée qui est utilisé par un programme réalisé en
.NET. La suppression et modification en cascade est donc réalisé
automatiquement par la partie application (avec les DataSet du .NET
Framework)...

Est-il conseillé de mettre une contrainte de clé étragère avec des NO
ACTION pour la modification/suppression ? Si oui pourquoi ?
Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

En vous remerciant par avance de vos lumières...

Cordialement

--
Gilles TOURREAU
Responsable informatique
gilles.tourreau@pos.fr

Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Philippe T [MS]
Bonjour,

Il est toujours préférable de mettre des contraintes d'intégrités au niveau
d'un modèle. D'une part cela permet de donner de la lisibilité a des
personnes devant travailler sur la base et qui ne connaissent pas le modèle
et d'autre part cela vous garantie justement l'intégrité référentielle !!!


Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
Salut tout le monde !

J'ai une base de donnée qui est utilisé par un programme réalisé en .NET.
La suppression et modification en cascade est donc réalisé automatiquement
par la partie application (avec les DataSet du .NET Framework)...

Est-il conseillé de mettre une contrainte de clé étragère avec des NO
ACTION pour la modification/suppression ? Si oui pourquoi ?
Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

En vous remerciant par avance de vos lumières...

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr




Avatar
SQLpro [MVP]
Philippe T [MS] a écrit :
Bonjour,

Il est toujours préférable de mettre des contraintes d'intégrités au niveau
d'un modèle. D'une part cela permet de donner de la lisibilité a des
personnes devant travailler sur la base et qui ne connaissent pas le modèle
et d'autre part cela vous garantie justement l'intégrité référentielle !!!



je compléterais en disant que c'est même affligeant de voir de telles
questions... L'essence même des SGBDR c'est le R pour relation, donc
intégrité de référence. Sans ce mécanisme, autant utiliser un fichier
Cobol, ce sera plus rapide !

Hélas, dans toutes les bases de données que j'ai audité jusqu'à présent
il y avait des basence d'IR, jusqu'à de nombreuses bases avec 0 IR !
Donc pollution de données, donc requêtes couteuses pour extraire des
données saines !


A +



Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
Salut tout le monde !

J'ai une base de donnée qui est utilisé par un programme réalisé en .NET.
La suppression et modification en cascade est donc réalisé automatiquement
par la partie application (avec les DataSet du .NET Framework)...

Est-il conseillé de mettre une contrainte de clé étragère avec des NO
ACTION pour la modification/suppression ? Si oui pourquoi ?
Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

En vous remerciant par avance de vos lumières...

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr










--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Gilles TOURREAU
SQLpro [MVP] a exposé le 13/06/2006 :
Philippe T [MS] a écrit :
Bonjour,

Il est toujours préférable de mettre des contraintes d'intégrités au niveau
d'un modèle. D'une part cela permet de donner de la lisibilité a des
personnes devant travailler sur la base et qui ne connaissent pas le modèle
et d'autre part cela vous garantie justement l'intégrité référentielle !!!



je compléterais en disant que c'est même affligeant de voir de telles
questions... L'essence même des SGBDR c'est le R pour relation, donc
intégrité de référence. Sans ce mécanisme, autant utiliser un fichier Cobol,
ce sera plus rapide !

Hélas, dans toutes les bases de données que j'ai audité jusqu'à présent il y
avait des basence d'IR, jusqu'à de nombreuses bases avec 0 IR !
Donc pollution de données, donc requêtes couteuses pour extraire des données
saines !


A +



Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
Salut tout le monde !

J'ai une base de donnée qui est utilisé par un programme réalisé en .NET.
La suppression et modification en cascade est donc réalisé automatiquement
par la partie application (avec les DataSet du .NET Framework)...

Est-il conseillé de mettre une contrainte de clé étragère avec des NO
ACTION pour la modification/suppression ? Si oui pourquoi ?
Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

En vous remerciant par avance de vos lumières...

Cordialement

-- Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr











Je vous remercie de vos réponses...

Mais ma question était faut-il comme même mettre des contraintes
d'intégrité avec aucune action (NO ACTION).

Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

C'est à dire quand on supprime/modifie un enregistrement dans une table
aucune autre action n'est réalisé... (Tout est fait au niveau de
l'applicatif .NET)...

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Avatar
Philippe T [MS]
Bonjour,

De mon coté, je n'aime pas les opérations effectués nativement en cascade
par le moteur. Je préfère explicitement le faire par programmation. Par
contre, je ne le fais pas coté application mais bien dans une procédure
stockée.

Une règle importante : ne jamais mettre de SQL en dehors de la base de
données !!!

Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
SQLpro [MVP] a exposé le 13/06/2006 :
Philippe T [MS] a écrit :
Bonjour,

Il est toujours préférable de mettre des contraintes d'intégrités au
niveau d'un modèle. D'une part cela permet de donner de la lisibilité a
des personnes devant travailler sur la base et qui ne connaissent pas le
modèle et d'autre part cela vous garantie justement l'intégrité
référentielle !!!



je compléterais en disant que c'est même affligeant de voir de telles
questions... L'essence même des SGBDR c'est le R pour relation, donc
intégrité de référence. Sans ce mécanisme, autant utiliser un fichier
Cobol, ce sera plus rapide !

Hélas, dans toutes les bases de données que j'ai audité jusqu'à présent
il y avait des basence d'IR, jusqu'à de nombreuses bases avec 0 IR !
Donc pollution de données, donc requêtes couteuses pour extraire des
données saines !


A +



Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
Salut tout le monde !

J'ai une base de donnée qui est utilisé par un programme réalisé en
.NET. La suppression et modification en cascade est donc réalisé
automatiquement par la partie application (avec les DataSet du .NET
Framework)...

Est-il conseillé de mettre une contrainte de clé étragère avec des NO
ACTION pour la modification/suppression ? Si oui pourquoi ?
Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

En vous remerciant par avance de vos lumières...

Cordialement

-- Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr











Je vous remercie de vos réponses...

Mais ma question était faut-il comme même mettre des contraintes
d'intégrité avec aucune action (NO ACTION).

Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

C'est à dire quand on supprime/modifie un enregistrement dans une table
aucune autre action n'est réalisé... (Tout est fait au niveau de
l'applicatif .NET)...

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr




Avatar
Pierre Goiffon
Philippe T [MS] wrote:
De mon coté, je n'aime pas les opérations effectués nativement en cascade
par le moteur. Je préfère explicitement le faire par programmation.



Sauf erreur, on peut très bien avoir une relation sans suppression en
cascade non ?
Avatar
Gilles TOURREAU
Pierre Goiffon avait prétendu :
Philippe T [MS] wrote:
De mon coté, je n'aime pas les opérations effectués nativement en cascade
par le moteur. Je préfère explicitement le faire par programmation.



Sauf erreur, on peut très bien avoir une relation sans suppression en cascade
non ?



Normalement oui, mais est-ce vraiment utile de créer cette relation ?

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Avatar
Gilles TOURREAU
Il se trouve que Philippe T [MS] a formulé :
Bonjour,

De mon coté, je n'aime pas les opérations effectués nativement en cascade par
le moteur. Je préfère explicitement le faire par programmation. Par contre,
je ne le fais pas coté application mais bien dans une procédure stockée.

Une règle importante : ne jamais mettre de SQL en dehors de la base de
données !!!

Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
SQLpro [MVP] a exposé le 13/06/2006 :
Philippe T [MS] a écrit :
Bonjour,

Il est toujours préférable de mettre des contraintes d'intégrités au
niveau d'un modèle. D'une part cela permet de donner de la lisibilité a
des personnes devant travailler sur la base et qui ne connaissent pas le
modèle et d'autre part cela vous garantie justement l'intégrité
référentielle !!!



je compléterais en disant que c'est même affligeant de voir de telles
questions... L'essence même des SGBDR c'est le R pour relation, donc
intégrité de référence. Sans ce mécanisme, autant utiliser un fichier
Cobol, ce sera plus rapide !

Hélas, dans toutes les bases de données que j'ai audité jusqu'à présent il
y avait des basence d'IR, jusqu'à de nombreuses bases avec 0 IR !
Donc pollution de données, donc requêtes couteuses pour extraire des
données saines !


A +



Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Gilles TOURREAU" wrote in message
news:
Salut tout le monde !

J'ai une base de donnée qui est utilisé par un programme réalisé en
.NET. La suppression et modification en cascade est donc réalisé
automatiquement par la partie application (avec les DataSet du .NET
Framework)...

Est-il conseillé de mettre une contrainte de clé étragère avec des NO
ACTION pour la modification/suppression ? Si oui pourquoi ?
Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

En vous remerciant par avance de vos lumières...

Cordialement

-- Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr











Je vous remercie de vos réponses...

Mais ma question était faut-il comme même mettre des contraintes
d'intégrité avec aucune action (NO ACTION).

Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

C'est à dire quand on supprime/modifie un enregistrement dans une table
aucune autre action n'est réalisé... (Tout est fait au niveau de
l'applicatif .NET)...

Cordialement

-- Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr







Je suis d'accord avec vous, mais nous développons une application qui
doit fonctionner sous différentes bases de données de différents
éditeurs.

Les procèdures stockées ne correspondent pas à notre besoin. En effet
il faut créer et maintenir différents code SQL pour les procèdures
stockées.

C'est pour cela que nous avons un module indépendant de l'IHM qui
réalise toutes les opérations nécessaires sur la base de données au
niveau application.

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
Avatar
Pierre Goiffon
Gilles TOURREAU wrote:
De mon coté, je n'aime pas les opérations effectués nativement en
cascade par le moteur. Je préfère explicitement le faire par
programmation.



Sauf erreur, on peut très bien avoir une relation sans suppression en
cascade non ?



Normalement oui, mais est-ce vraiment utile de créer cette relation ?



?!!!
Pourquoi utiliser un SGBD si c'est pour assurer toute l'intégrité
référentielle côté applicatif ??
Avatar
SQLpro [MVP]
Gilles TOURREAU a écrit :
[...]

Je vous remercie de vos réponses...

Mais ma question était faut-il comme même mettre des contraintes
d'intégrité avec aucune action (NO ACTION).




je pense que vous vous méprenez sur le sens du NO ACTION qui est en fait
un quasi synonyme de RESTRICT.

Démonstration :

CREATE TABLE T_MERE
(CLE_MER INT NOT NULL PRIMARY KEY)

CREATE TABLE T_FILLE
(CLE_FIL INT NOT NULL PRIMARY KEY,
CLE_MER INT FOREIGN KEY REFERENCES T_MERE (CLE_MER) ON UPDATE NO
ACTION ON DELETE NO ACTION)

INSERT INTO T_MERE VALUES (1)
INSERT INTO T_MERE VALUES (2)
INSERT INTO T_MERE VALUES (3)

INSERT INTO T_FILLE VALUES (100, 1)
INSERT INTO T_FILLE VALUES (101, 7)

--=> Serveur : Msg 547, Niveau 16, État 1, Ligne 1
--=> Conflit entre l'instruction INSERT et la contrainte COLUMN FOREIGN
KEY 'FK__T_FILLE__CLE_MER__00551192'. Le conflit est survenu dans la
base de données 'test', table 'T_MERE', column 'CLE_MER'.
--=> L'instruction a été arrêtée.

DELETE FROM T_MERE
WHERE CLE_MER = 1

--=> Serveur : Msg 547, Niveau 16, État 1, Ligne 1
--=> Conflit entre l'instruction DELETE et la contrainte COLUMN
REFERENCE 'FK__T_FILLE__CLE_MER__00551192'. Le conflit est survenu dans
la base de données 'test', table 'T_FILLE', column 'CLE_MER'.
--=> L'instruction a été arrêtée.

UPDATE T_MERE
SET CLE_MER = 9
WHERE CLE_MER = 1

--=> Serveur : Msg 547, Niveau 16, État 1, Ligne 1
--=> Conflit entre l'instruction UPDATE et la contrainte COLUMN
REFERENCE 'FK__T_FILLE__CLE_MER__00551192'. Le conflit est survenu dans
la base de données 'test', table 'T_FILLE', column 'CLE_MER'.
--=> L'instruction a été arrêtée.

Comme vous pouvez le constater NO ACTION a bien entrainé
systématiquement un viol de contrainte comme l'aurait fait RESTRICT.

En fait la différence est TRES subtile : RESTRICT est une contrainte
déferrable et NO ACTION interdit la défarrabilité.
Comme cette notion n'est pas gérée dans SQL Server, l'effet est le même.

Dans d'autres SGBR, comme Oracle, DB2 ou PostGreSQL en fonction de la
façon dont est géré la déférabilité de la contrainte, le RESTRICT
permettra d'inserer la ligne même s'il y a violation de clef, à
condition que ce viol de clef soit temporaire et que la situation
devienne finalement cohérente avant la fin de la transaction.
Autrement dit en RESTRICT avec déférabilité et dans le cadre d'une
transaction, je peut insérer une commande faisant référence à un client
inexistant, puis ajouter ce nouveau client et le commit vérifiera la
contrainte au finish et non à priori (c'est à dire à l'insertion de la
ligne) comme il l'aurait fait pour du NO ACTION.

Si vous voulez de plus amples informations sur les notions de
déérabilité des contraintes, je vous invite à lire mon bouqui sur SQL
qui en parle de façon détaillé.

http://sqlpro.developpez.com/booksql05/

A +



Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

C'est à dire quand on supprime/modifie un enregistrement dans une table
aucune autre action n'est réalisé... (Tout est fait au niveau de
l'applicatif .NET)...

Cordialement





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Gilles TOURREAU
SQLpro [MVP] a présenté l'énoncé suivant :
Gilles TOURREAU a écrit :
[...]

Je vous remercie de vos réponses...

Mais ma question était faut-il comme même mettre des contraintes
d'intégrité avec aucune action (NO ACTION).




je pense que vous vous méprenez sur le sens du NO ACTION qui est en fait un
quasi synonyme de RESTRICT.

Démonstration :

CREATE TABLE T_MERE
(CLE_MER INT NOT NULL PRIMARY KEY)

CREATE TABLE T_FILLE
(CLE_FIL INT NOT NULL PRIMARY KEY,
CLE_MER INT FOREIGN KEY REFERENCES T_MERE (CLE_MER) ON UPDATE NO ACTION ON
DELETE NO ACTION)

INSERT INTO T_MERE VALUES (1)
INSERT INTO T_MERE VALUES (2)
INSERT INTO T_MERE VALUES (3)

INSERT INTO T_FILLE VALUES (100, 1)
INSERT INTO T_FILLE VALUES (101, 7)

--=> Serveur : Msg 547, Niveau 16, État 1, Ligne 1
--=> Conflit entre l'instruction INSERT et la contrainte COLUMN FOREIGN KEY
'FK__T_FILLE__CLE_MER__00551192'. Le conflit est survenu dans la base de
données 'test', table 'T_MERE', column 'CLE_MER'.
--=> L'instruction a été arrêtée.

DELETE FROM T_MERE
WHERE CLE_MER = 1

--=> Serveur : Msg 547, Niveau 16, État 1, Ligne 1
--=> Conflit entre l'instruction DELETE et la contrainte COLUMN REFERENCE
'FK__T_FILLE__CLE_MER__00551192'. Le conflit est survenu dans la base de
données 'test', table 'T_FILLE', column 'CLE_MER'.
--=> L'instruction a été arrêtée.

UPDATE T_MERE
SET CLE_MER = 9
WHERE CLE_MER = 1

--=> Serveur : Msg 547, Niveau 16, État 1, Ligne 1
--=> Conflit entre l'instruction UPDATE et la contrainte COLUMN REFERENCE
'FK__T_FILLE__CLE_MER__00551192'. Le conflit est survenu dans la base de
données 'test', table 'T_FILLE', column 'CLE_MER'.
--=> L'instruction a été arrêtée.

Comme vous pouvez le constater NO ACTION a bien entrainé systématiquement un
viol de contrainte comme l'aurait fait RESTRICT.

En fait la différence est TRES subtile : RESTRICT est une contrainte
déferrable et NO ACTION interdit la défarrabilité.
Comme cette notion n'est pas gérée dans SQL Server, l'effet est le même.

Dans d'autres SGBR, comme Oracle, DB2 ou PostGreSQL en fonction de la façon
dont est géré la déférabilité de la contrainte, le RESTRICT permettra
d'inserer la ligne même s'il y a violation de clef, à condition que ce viol
de clef soit temporaire et que la situation devienne finalement cohérente
avant la fin de la transaction.
Autrement dit en RESTRICT avec déférabilité et dans le cadre d'une
transaction, je peut insérer une commande faisant référence à un client
inexistant, puis ajouter ce nouveau client et le commit vérifiera la
contrainte au finish et non à priori (c'est à dire à l'insertion de la ligne)
comme il l'aurait fait pour du NO ACTION.

Si vous voulez de plus amples informations sur les notions de déérabilité des
contraintes, je vous invite à lire mon bouqui sur SQL qui en parle de façon
détaillé.

http://sqlpro.developpez.com/booksql05/

A +



Du style :

ADD CONSTRAINT MaContrainte FOREIGN KEY (CléEnfant) REFERENCES Parent
(CléParent) ON DELETE NO ACTION ON UPDATE NO ACTION

C'est à dire quand on supprime/modifie un enregistrement dans une table
aucune autre action n'est réalisé... (Tout est fait au niveau de
l'applicatif .NET)...

Cordialement






Voilà qui est plus clair...

Je vous remercie de vos explications.

Cordialement

--
Gilles TOURREAU
Responsable informatique


Société P.O.S
Spécialiste en motoculture depuis + de 30 ans !
http://www.pos.fr
1 2