Discussion :

[Emmanuel Lecoester]

Qui n'a jamais débattu avec un collègue sur l'utilité de l'utilisation ou non de clés étrangères dans le SGBD.

Ce nouveau tutoriel de sqlpro nous permet d'aborder ce sujet à partir de cas pratiques.

http://sqlpro.developpez.com/article/fk-sql-vs-appli/

Et vous ce tutoriel vous a-t-il convaincu ?


Retrouvez tous les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server

[fsmrel]

Ça me rajeunit de 20 ans...

Dès que DB2 nous permit enfin d’assurer l’intégrité référentielle, je l’ai mise en œuvre d’office (c’était en 1988, et à l’époque aucun SGBD n’avait encore suivi les recommandations de Codd et de Date à ce sujet). Par contre, nombre de ceux qui la réclamaient à grands cris, se sont abstenus, trouvant tout à coup qu’elle pouvait poser a priori des problèmes de performance, mais sans qu'ils effectuent les travaux de prototypage ad-hoc... C’est du passé, mais il reste toujours quelques irréductibles, et ceux-là doivent avoir bien des orphelins dans leurs tables, même s’ils sont persuadés du contraire (j'ai pu m'en assurer, à coups d'audits...)

A noter que le père du concept formel d’intégrité référentielle est — comme par hasard — Ted Codd (voyez Extending the Database Relational Model to Capture More Meaning).

[mikedavem]

Bon au contraire de fsmrel ca ne rajeunit pas de 20 ans ... j'étais encore trop petit à ce moment là

Un très bon article comme d'habitude que devrait lire n'importe quel éditeur d'ERP. J'ai encore vu il y a un an une entreprise qui utilisait un ERP où aucune integrité référentielle au niveau base n'était implémenté et ceci sur DB2 .... C'était l'application qui gérait cela .... La conséquence ? Simple , une mauvaise qualité de données (doublons, enregistrements orphelins) ... et des problèmes de maintenance qui s'en suivent ...

++

[Mat.M]

J'ai encore vu il y a un an une entreprise qui utilisait un ERP où aucune integrité référentielle au niveau base n'était implémenté et ceci sur DB2 .

est-ce qu'on peut connaitre le nom de l'ERP ?
Sinon m'écrire en MP

[tatayo]

Bha, L'ERP que nous utilisons n'implémente pas d'intégrité référentielle (base Progress), ni le logiciel de WMS (SqlServeur) , ni le logiciel d'encaissement (que ce soit la partie serveur ou la partie client sur la caisse, toutes les deux sur SqlServeur)... Pour l'application de Paie (SqlServeur aussi), je ne suis pas sûr, et la compta (SqlServeur) je suis persuadé que non.

Tatayo.

[Fabien Celaia]

En introduction : je suis pour l'implémentation des FK et PK au niveau de la base, car ça limite, et je suis pour la modélisation propre et les FN...

Ceci étant dit, un ERP est fait pour être "monolithique", donc avoir un frontal spécifique au modèle de donnée sous-jacent, et gérer "tout en un".

Je n'en ai pas touché des tonnes : juste SAP et Peoplesoft, mais ils ont les 2 les mêmes points communs

1) une tonne de tables
2) un modèle pas vraiment normalisé
3) une indexation erratique
4) une interdiction d'attaquer la base sous un autre angle que le frontal dédié

[spdev666]

Très bon argumentaire (en même temps, j étais déjà convaincu ).

Par contre, ce serait intéressant qu un "anti - FOREIGN KEY" défende son point de vue.

[ILP]

Un article à distribuer auprès de mes collègues. Là je dois importer des données dans une base de données Firebird (qui accepte les contraintes FOREIGN KEY). Je n'ai aucune clé primaire, encore moins de clé étrangère.
Et cerise sur le gâteau : les index des tables sont enregistrées dans une table MAX_ID, avec un champ pour chaque table. La valeur de ces champs étant incrémentées à chaque INSERT .
Je suis désespéré .

[doc malkovich]

Snif, et le décisionnel alors ?
Un exemple pertinent où les FK sont gérées dans le code ?
En effet, on "nettoie" les données dans l'ODS, et on capture les enregistrements défaillants ...

[SQLpro]

Salut,

Snif, et le décisionnel alors ?
Un exemple pertinent où les FK sont gérées dans le code ?
En effet, on "nettoie" les données dans l'ODS, et on capture les enregistrements défaillants ...

C'est pas une bonne méthode.... Mieux vaut utiliser une base tampon pour faire l'alimentation et que les lignes rejetées restent dans la base tampon.
Dès lors il y a toujours un décisionnel clean et au pire on peut voir les lignes "défaillantes" en prévoyant des vues qui font l'UNION ALL des tables entre les deux bases....

Comme quoi il existe TOUJOURS une solution pour bien faire les choses !

A +

[doc malkovich]

Hello mr sqlpro !

Mieux vaut utiliser une base tampon pour faire l'alimentation et que les lignes rejetées restent dans la base tampon

yaisse, c'est ce qu'on appelle l'ODS dans notre jargon de décisionneux
mais si on garde les rejets dans cette base tampon, tu es d'accord qu'il n'y a pas de FK sgbd sur cette base ? sinon adios les rejetos ...
après au niveau perfs on a aussi tendance à virer les FK du coup chez nous ...
c'est un cas particulier ( il faut dire que la bi c'est un peu particulier ) ...
ou alors j'ai loupé un truc ...

[Invité]

Très bon argumentaire (en même temps, j étais déjà convaincu ).

Par contre, ce serait intéressant qu un "anti - FOREIGN KEY" défende son point de vue.

Je ne suis pas anti foreign key, juste pragmatiquement enclin à réfléchir avant de les implémenter.
Je ne suis pas emballé par le système arguments-contradiction, c'est un jeu de politicien, j'ai une appli à gérer pas des écoliers... Parfois la théorie tue un projet un peu pollué : mais passons aux exemples

Primo :
Gérer les contraintes via le sgbd suppose une remontée des messages d'erreur de la base : puis il faut gérer ces messages. Or ils n'ont pas toujours le même sens selon qu'on est en design-time ou au run time. Il peut être bien moins couteux de définir une politique de contraintes serveur souples plutôt que bloquer un client en prod sur un message du style ORA-ERR 1877...

secundo :
si mon code client fait une "bétise" et supprime une ligne parente non-protégée : je peux préférer connecter la base en admin, trouver les lignes orphelines et me faire ma propre idée de ce qu'il faut faire plutot que laisser l'utilisateur gérer une erreur dont il ne sait que faire.

Tertio :
Messieurs les gourous de BDD merci de ne pas vous approprier les SGBD : Certaines applis en font un usage que vous n'imaginez pas et pour lequel vous n'avez pas forcément l'expertise ad hoc. Traitement de signal, stockage de flux paginé, liaisons anticipées sont monnaie courante dans ma spécialité et tout ceci est assez loin des questions de foreign keys.

D'autre part : gérer un mauvais client sur lequel on n'a pas la main est aussi le type de pollution à laquelle on peut être confronté. Parfois le théorie vous éloigne de la pratique et c'est le cas ici. Très théorique cette approche, décidément.

Comme manager, si mon gars ne gère pas les foreign keys mais qu'il sait bien faire des stats, je lui pardonne volontiers car je peux mettre des contraintes à postériori sur la base de tests solides, alors que je ne peux pas forcément remplacer un bon designer.

vous vouliez des arguments...

[Luc Orient]

... si mon code client fait une "bétise" et supprime une ligne parente non-protégée : je peux préférer connecter la base en admin, trouver les lignes orphelines et me faire ma propre idée de ce qu'il faut faire plutot que laisser l'utilisateur gérer une erreur dont il ne sait que faire.

J'ai un peu de mal à voir ce qu'on peut faire avec une facture supprimée alors qu'il reste des lignes de factures rattachées à rien ... Et puis pragmatisme contre pragmatisme, en tant que DBA j'ai suffisamment de travail à faire sans perdre mon temps à faire ce genre de manipulation sans interêt ...

[Invité]

J'ai un peu de mal à voir ce qu'on peut faire avec une facture supprimée alors qu'il reste des lignes de factures rattachées à rien ... Et puis pragmatisme contre pragmatisme, en tant que DBA j'ai suffisemment de travail à faire sans perdre mon temps à faire ce genre de manipulation sans interêt ...

Vous avez oublié de préciser que cet article est strictement limité à la gestion ... non ? Ces jours ci j'administre des serveurs BDD dont AUCUN ne fait de gestion .. Une base de données sert aussi à gérer un filesystem ou une liste de périphériques ou un flux ou..... du traitement de signal

Su les 3 pays où je travaille , seule la France ignore cela. Education ?
J'ai écrit des compilateurs en SQL il y a une 10aine d'années , les lignes orphelines étaient des liens morts et aucun utilisateur n'aurait pu gérer les millions de messages d'intégrité , c'est la force dune BDD , elle peut jointurer à postériori. Mais ce me semble limite louche chez vous, ne comptez vous que des sous ? C'est un peu réducteur quand même

Pensez vous que les aiguilleurs du ciel se voient interdire l'usage de BDD ? et les milliers de taches sur leur écran radar = autant de lignes de BDD avec ou sans contrainte FK ?? Messieurs voyez un peu large svp

[Oishiiii]

Le sujet ici est les clé étrangères en SQL et donc indirectement la Théorie Relationnelle.
La normalisation qui a pour but entre autre de réduire la redondance d'information entraine un nombre de tables relativement important. Celles-ci sont très souvent en associées (je n'utilise pas le mot relation volontairement).

Vous pouvez très bien vous servir de tables comme de vulgaires sacs ou espaces de stockage, c'est peut-être parfois nécessaire dans votre cas.

Mais les contraintes de clé étrangère sont tout simplement indispensables lorsqu'il faut garantir l'intégrité des données de la base.

Si vous n'avez aucune contraintes.. comment savez-vous quel brevet a passé un pilote et par conséquent s'il est autorisé à piloter tel type d'avion ?

[Luc Orient]

... Mais ce me semble limite louche chez vous, ne comptez vous que des sous ? C'est un peu réducteur quand même

Non c'est normal pour moi ... je travaille dans une banque ...

[CinePhil]

Primo :
Gérer les contraintes via le sgbd suppose une remontée des messages d'erreur de la base : puis il faut gérer ces messages. Or ils n'ont pas toujours le même sens selon qu'on est en design-time ou au run time. Il peut être bien moins couteux de définir une politique de contraintes serveur souples plutôt que bloquer un client en prod sur un message du style ORA-ERR 1877...

Avant de filer une appli au client, on la teste non ?
Et si ce genre de message d'erreur intervient... ben on intervient pour qu'il n'intervienne plus chez le client !

secundo :
si mon code client fait une "bétise" et supprime une ligne parente non-protégée : je peux préférer connecter la base en admin, trouver les lignes orphelines et me faire ma propre idée de ce qu'il faut faire plutot que laisser l'utilisateur gérer une erreur dont il ne sait que faire.

Je pense que le DBA va t'envoyer sur les roses avant la dixième intervention que tu lui demanderas !

Tertio :
Messieurs les gourous de BDD merci de ne pas vous approprier les SGBD : Certaines applis en font un usage que vous n'imaginez pas et pour lequel vous n'avez pas forcément l'expertise ad hoc.

Bien sûr, les spécialistes en BDD sont spécialistes... en BDD pas en traitement de signal et autres sujets probablement très intéressants cités juste après.
Mais ils posent des questions pour concevoir correctement la BDD qui sera utilisé par le spécialiste du domaine et lui font valider la conception et l'appli avant de lui permetre de jouer avec.

Traitement de signal,

Sans connaître ce domaine, le signal vient d'une source non ?
Tiens, voilà déjà un bout de MCD :
Signal -1,1----Provenir----0,1- Source
Bon je vais vite sur ce bout de schéma mais c'est pour montrer qu'on peut probablement modéliser à peu près tout.

stockage de flux paginé, liaisons anticipées sont monnaie courante dans ma spécialité et tout ceci est assez loin des questions de foreign keys.

Ces domaines là, je ne les connais pas du tout et ne peux donc pas actuellement les modéliser mais avec un peu plus d'informations je suis sûr qu'on doit arriver à quelque chose.

D'autre part : gérer un mauvais client sur lequel on n'a pas la main est aussi le type de pollution à laquelle on peut être confronté. Parfois le théorie vous éloigne de la pratique et c'est le cas ici. Très théorique cette approche, décidément.

Si le client est mauvais, son fournisseur doit l'être aussi ?
Remarque, c'est peut-être un bon moyen de se débarrasser des mauvais clients après tout !

Comme manager, si mon gars ne gère pas les foreign keys mais qu'il sait bien faire des stats,

Ce n'est pas le même boulot.

je lui pardonne volontiers car je peux mettre des contraintes à postériori sur la base de tests solides,

Tests qui prendront du temps à élaborer, à analyser les résultats. Contraintes qui ne fonctionneront peut-être pas parce que des contraintes d'intégrité n'auront pas été implantées au préalable et il faudra alors perdre encore du temps à chercher les erreurs et du temps à les corriger.

alors que je ne peux pas forcément remplacer un bon designer.

Tu auras aussi peut-être autant voire plus de mal à remplacer un bon concepteur de BDD.

Pensez vous que les aiguilleurs du ciel se voient interdire l'usage de BDD ? et les milliers de taches sur leur écran radar = autant de lignes de BDD avec ou sans contrainte FK ?? Messieurs voyez un peu large svp

Les "milliers de taches sur leur écran radar = autant" d'avions avec des humains dedans !
Pas rassurant ce que tu as écrit là !
J'espère que les applis des aiguilleurs du ciel utilisent des BDD solides !

[plemaire]

Les "milliers de taches sur leur écran radar = autant" d'avions avec des humains dedans !
Pas rassurant ce que tu as écrit là !
J'espère que les applis des aiguilleurs du ciel utilisent des BDD solides !

Je me demande dans tel cas, l'importance de la BDD par rapport à l'ensemble du système.
Les Paraboles ? Les Antennes ? les Recepteurs éléctroniques ? les protocoles et signaux ? l'application elle même ?

La BDD est un outil GENERALISTE, qu'il convient d'utiliser à bon escient dans une application SPECIFIQUE. et si cela imlpique de NE PAS utiliser les FK, je ne vois pas en quoi cela choque. Et je ne comprend pas non plus, comment sans connaitre le besoin fonctionnel et Technique, on peut être aussi catégorique.

[Pierre Fauconnier]

Ne pas poser les contraintes dans la base et déléguer ce travail uniquement au logiciel revient à ne permettre l'utilisation des données que via le logiciel qui gère lesdites contraintes...

Au vu de ce que je rencontre quotidiennement en entreprise, cette approche n'est pas réaliste et empêche la centralisation des données en un seul endroit, avec x logiciels qui se connectent au "datawharehouse"...

[_skip]

A ma connaissance, qu'un programme client plante à cause d'une contrainte d'intégrité qu'il a violée suite à une situation bizarroïde de concurrence, c'est plus facilement acceptable et réparable que des dégâts au niveau de la cohérence des données.

Je suis plutôt partisan de dire que malgré tout le soin apporté à la gestion de situations difficiles dans un code client, le risque de bug est bien présent et des choses inattendues peuvent se produire.
Je préfère un bon gros plantage de mon application avec un message hideux plutôt que prendre le risque d'une insertion/modification foireuse qui se produirait silencieusement. Car ensuite, trouver l'erreur est déjà une chose, l'expliquer peut être très difficile et dans tous les cas la responsabilité du fournisseur de l'application ainsi que sa crédibilité peuvent rentrer en jeu.

Les contraintes ne sont pas la réponse à tout, mais sont toutefois une sécurité supplémentaire non négligeable. D'autant que la portabilité me semble pas si problématique que telle qu'exprimée dans le post précédent.