Discussion :

[The_Big_Lebowski]

Bonjour
j'aimerais savoir a quoi servent les foreign keys au niveau de l'utilisation

Je sais bien qu une FK permet au SGBD de controler la relation entre 2 tables ou plus et evite par inadvertance de supprimer des informations liées les unes aux autres.

Si je gere, par code (objets metiers), les relations de ma base concernant la suppression des informations liées (suppression en cascade par exemple) quel est l'interet de mettre en place ces foreign keys ?

Merci

[scheu]

Ca a un intérêt pour les performances
Si la foreign key est présente, quand tu fais des requêtes de jointure sur les colonnes de ta foreing key, l'optimiseur sait comme ça que toute valeur dans la table fille existent aussi dans la table mère et ça peut aider à avoir un meilleur plan d'exécution et donc de meilleurs performances

L'inconvénient c'est que si tu fais beaucoup d'insertions en masse dans la table fille, la foreign key peut légèrement ralentir le chargement car pour chaque enreg Postgresql va vérifier si la valeur existe dans la table mère

De plus quand tu dis "c'est géré par l'appli", déclarer la FK sur la base constitue une sécurité en plus d'avoir des données cohérentes. Par expérience si ton appli évolue ou rencontre un problème, tu as toujours un risque d'avoir des lignes "orphelines en base"

Bref il y a toujours un compromis à trouver entre performances au chargement et performances en restitution, c'est à toi de bien tester d'abord avec une volumétrie réelle pour ne pas avoir de mauvaises surprises

[SQLpro]

De plus quand tu dis "c'est géré par l'appli", déclarer la FK sur la base constitue une sécurité en plus d'avoir des données cohérentes. Par expérience si ton appli évolue ou rencontre un problème, tu as toujours un risque d'avoir des lignes "orphelines en base"

De plus vos import sde données sont gérées par l'appli ?
L'administrateur du SGBDR n'a aucune autorisation de mise à jour des données ??

Et même si vous vérifiez au niveau de votre application, entre le moment ou vous faite cette vérification et le moment ou vous allez faire l'insertion quelqu'un en parallèle a pu supprimer la référence. Donc vous vous trouverez dans la m...

Sauf à gérer des transactions côté client qui bloque tout et rendent le SGBDR catastrophiquement lent, il est strictement impossible de faire cela côté client !

A +

[The_Big_Lebowski]

Merci de vos explications à Scheu et un bonjour tout particulier à Frédéric BROUARD,

nous avons travaillé dans la même entreprise il y a quelques temps je ne sais pas si tu te souviens (à brignoles) je te transmets mon bon souvenir, j'ai toujours ton bouquin dédicacé et j'y accède de temps en temps

désolé pour le message personnel

De plus vos import sde données sont gérées par l'appli ?
L'administrateur du SGBDR n'a aucune autorisation de mise à jour des données ??

L'import des données est bien evidemment géré par l'appli (un back office)

Et l'administrateur n'a pas à intégrer des données (en théorie) rien ne l'empeche de trouver un Front Office (pgAdmin par exemple) et de manipuler les données mais a ses risques et perils, non ?
Les données lui appartiennent et je lui restitue par l'intermédiaire de mon appli mais la structure m'appartient.

Quoi qu il en soit, j'ai bien compris le message et vais faire le necessaire pour effectivement y intégrer a nouveau mes FK.
J'avais construit ma base comme ca a l'origine mais le script de création de celle-ci devenait chiant a traiter vu que les tables doivent être créées dans un ordre bien precis (1 fichier .sql pour chaque table (c'est MA convention) plus facile à faire évoluer).

Je vais donc ajouter un fichier de création de ces FK que je traiterai à la fin de mon script de génération de la base, est-ce logique ?

Merci à vous 2

[scheu]

"L'ordre bien précis" comme tu dis est embêtant à première vu, mais est en réalité salvateur pour être sûr de toujours avoir des données cohérentes.
Sans cela, bonjour les clés parentes non trouvées ...

[SQLpro]

OK pour message personnel !!! Bon vent pour la suite...

J'avais construit ma base comme ca a l'origine mais le script de création de celle-ci devenait chiant a traiter vu que les tables doivent être créées dans un ordre bien precis (1 fichier .sql pour chaque table (c'est MA convention) plus facile à faire évoluer).

Vous n'avez pas à vous préoccuper de l'ordre de création si :
a) vous construisez vos table au sein d'un schéma. Voir l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p5...es-schema-sql/
b) vous séparez votre script en deux : d'un côté les CREATE TABLE, de l'autre les ALTER TABLE ... ADD CONSTRAINT .... FOREIGN KEY

je suis en train d'écrire un article sur les énormités que provoque l'absence de FK....

A +

[The_Big_Lebowski]

Merci pour ces infos
je considere desormais ce post comme résolu