Discussion :

[fsmrel]

quelqu'un ici a déjà jeté un oeil au modèle de donnée utilisé par SAP?

Où peut-on le trouver ?

A votre expression, on a le sentiment qu’il doit être bien difficile de le décrypter, et de savoir s’il contient telle ou telle information. Comme dirait Codd, relève-t-il du « CIA-type programming » ? Ou plus simplement, le principe d'intégrité référentielle y serait-il ignoré ?

[Waldar]

Sortons des concepts logiciens et soyons pragmatiques avec une situation réelle.

Un de vos fournisseurs vous envoie ses ventes facturées et un jour, pour une raison X ou Y, erreur de batch, erreur d'applicatif en amont, il ne vous envoie pas de code client associé.

Que faites-vous ?

[fsmrel]

Sortons des concepts logiciens et soyons pragmatiques avec une situation réelle.

Un de vos fournisseurs vous envoie ses ventes facturées et un jour, pour une raison X ou Y, erreur de batch, erreur d'applicatif en amont, il ne vous envoie pas de code client associé.

Que faites-vous ?

Si cela ne vous ennuie pas, ne faisons pas d’amalgame, restons au niveau (formel) du sujet traité, à savoir celui de l’intégrité référentielle. Je ne bricolerai en aucune façon la structure de la base de données (et a fortiori le MCD ou le DC) pour des aspects contingents, qui concernent la Production informatique (erreur dans l’enchaînement des batchs) et les Études (erreur de l’applicatif). Le principe est de rejeter les anomalies et d’utiliser les circuits et mécanismes prévus de correction des erreurs, toutes choses définies et décrites dans les dossiers de conception et de production. Ça n’est quand même pas a posteriori que je vais inventer une procédure de rattrapage du genre absence du code client associé aux factures du jour. Tant pis si les tableaux de bord arrivent en retard sur le bureau de ces messieurs et si les informaticiens se font taper sur les doigts (ça m'est arrivé...)

[Pierre Fauconnier]

...
Je suis également contre (et là je suis sûr que des gens seront pas d'accord) le fait de faire des vérifications dans le code client EN PLUS de celles faites par la base de donnée. Par exemple si je veux supprimer un Produit, j'envoie directement un DELETE et je réagis sur l'exception, les vérifications préalables sont lourdes à écrire, couteuses en performance et au final peu rassurantes et difficiles à maintenir. Enfin c'est mon avis....

Je suis de ton avis, mais effectivement, d'autres pas, comme en témoigne cette discussion...

A propos de l'article, je trouve qu'on ne gagne rien à dire que celui qui n'utilise pas les contraintes référentielles est stupide. Ce n'est pas un argument sérieux.
Sans cela l'article aurait été parfait.

C'est toute la différence entre le fond et la forme...

[fsmrel]

A l'attention des correcteurs :

Je signale une coquille au paragraphe V-3.

Il faut remplacer "Peter Chen (père du modèle relationel)" par "Peter Chen (traditionnellement considéré comme le père du modèle Entité/Relation)".

[SQLpro]

En BI on peut aussi faire en sorte de faire pointer les rejetons sur une ligne bidon et du coup on peut garder les FK.

Ne serais-ce que pour comprendre les schéma, ça me semble essentiel.

Non jester votre solution n'est pas bonne car si vous voulez faire des statistiques globales elle seront fausse parce que l'échantillon admet cette erreur sciemment !
Or il vaut mieux faire des stats sur un jeu de données restreint et juste que sur un jeu agrandit et faux...

Par exemple si votre client bidon n'est pas un seul client, mais plusieurs, les stats sur le nombre de vente par client seront salement fausses. Et faire un filtre pour éliminer ce seul client implique que l'index ne sera plus utilisable, de même que les calculs d'agrégats pré établis.

En revanche je peut avoir parfois besoin de ces données supplémentaires dans certains cas.

Encore une fois Jester, vous cherchez toujours la facilité, mais n'en comprenez pas les subtiles implications....

A +

[fsmrel]

Défense et illustration de l'intégrité référentielle.

Quitte à me répéter, je reprends une fois encore un échantillon d'expériences que j'ai vécues chez ceux qu'on appelle les "grands comptes".

Peut-on faire l'impasse sur le contrôle de l'intégrité référentielle par le SGBD ? Demander à l’application de garantir l’intégrité des données suffit-il ?

Dans le cas des applications traditionnelles de gestion, mais néanmoins centrales, vitales, dans le monde des entreprises telles que les banques, les sociétés d’assurance, les caisses de retraite, dans la distribution, l’industrie, les administrations, etc., la réponse est non, car il peut en résulter de très sérieux dommages. A suivre, quelques péripéties dans lesquelles j’ai trempé, dépêché par mon entreprise (une SSII).

Il était une banque où je fus appelé pour tenter de rétablir les liens entre les tables des comptes, des contrats, des clients, etc. La cata. J’ai tout tenté pour remettre les choses d’aplomb. Le Président lui-même me posait tous les matins la même question dans laquelle l’angoisse était à peine voilée : « Alors ? mes en-cours ? » Peine perdue. La banque n’existe plus.

Une société d’assurance. Pour le DSI, la base de données Clients c’était du béton : « Je n’ai jamais entendu parler de quelque problème que ce soit, tout baigne ». J’étais alors chargé de valider un modèle conceptuel de données et le modèle logique dérivé, ceci pour une autre base, alimentée à partir des données de production. Ayant mis en œuvre l’intégrité référentielle pour la nouvelle base, ce qui devait arriver arriva, ce fut un révélateur : 30% de données rejetées lors de la « remontée » dans la base toute neuve. Le DSI verdit et il fallut plus d’un an pour arriver à remettre la base Clients à peu près d’équerre.

Une société de crédit automobile. Pour valider une application en cour de refonte, j’avais été autorisé à copier les données de production. Je fus obligé de porter le pet au plus vite, car il y avait quelques milliers de contrats faisant référence à des clients inconnus au bataillon. Panique à bord, tout le monde sur le pont... Après enquête, il s’est avéré que, suite à un incident matériel en production, il y avait eu une restauration des données Clients/Contrats, mais à partir d’une sauvegarde des clients ayant eu lieu à une date n’ayant rien à voir avec la date de sauvegarde des contrats. Heureusement, il y avait un an de backup en magasin et le coup put être rattrapé. (Le SGBD n’était pas relationnel. Il a par la suite été remplacé par DB2, lequel aurait tout de suite détecté le décalage des sauvegardes.)

Une caisse de retraite. Un décideur (fonctionnel) décide de faire débrancher l’intégrité référentielle pour une partie de la base de données. Prudent, je recopie les tables de production dans un environnement qu’on m’a affecté, j’écris toutes les requêtes SQL pour vérifier (de nuit, car il est hors de question de pomper du temps machine pendant la journée) que les tables impliquées sont restées cohérentes suite à traitement diurne. Au résultat, ça n’a pas traîné : je constate que 780000 périodes passées par les cotisants dans les entreprises se sont envolées (peut-être étaient-ce les vôtres ?) Traitements à refaire, avec ordre cette fois-ci du décideur de brancher l’intégrité référentielle. Qu’est-ce qu’il ne faut pas faire pour que les gens comprennent...

Et j’en ai bien d’autres...

Il faut être vraiment naïf pour croire que les contrôles d’intégrité assurés par programme permettent de dormir sur ses deux oreilles. Après tout, dans la série « ceinture, bretelles et épingle à nourrice », si vous avez un DBA sous la main, tout en laissant l’application consciencieusement contrôler ce qu’elle à a à contrôler, demandez donc à ce spécialiste de mettre en œuvre l’intégrité référentielle, au moins pour les tables les plus sensibles, ou (si le chef refuse), de développer et exécuter les requêtes permettant d’auditer le contenu des tables.

Par référence aux trois petits cochons, il faut préférer construire une maison en briques plutôt qu’en paille et implanter l’intégrité référentielle. Attention au loup.

[Jester]

Par exemple si votre client bidon n'est pas un seul client, mais plusieurs, les stats sur le nombre de vente par client seront salement fausses. Et faire un filtre pour éliminer ce seul client implique que l'index ne sera plus utilisable, de même que les calculs d'agrégats pré établis.

Encore une fois Jester, vous cherchez toujours la facilité, mais n'en comprenez pas les subtiles implications....

Et vous ne lisez toujours pas ce que j'écris et inventez des choses que je n'ai pas dites. J'ai dit que c'est à utiliser ou non au cas par cas.

A part des critiques je n'ai pas lu de solutions à ce problème. Waldar a un peu spécifié le problème aussi, on a pas daigné lui répondre.

[fsmrel]

J'ai dit que c'est à utiliser ou non au cas par cas.

A part des critiques je n'ai pas lu de solutions à ce problème.

Pour ma part, je vous ai indiqué la méthode à suivre :

http://www.developpez.net/forums/d82...t/#post4713159

Je suis désolé, mais la modélisation est un travail de fond, il n'y a pas d'improvisation et ça demande de l'expérience, on n'a pas le choix. A défaut, on découvre les problèmes à chaud et forcément leur résolution en devient d'autant plus délicate. Ainsi ai-je vu une très, très grande entreprise apprenant grâce à des « statistiques » accouchées au forceps, qu'en une journée elle vendait plus qu'elle ne le faisait en réalité pendant un mois. Le problème était que le père du MCD (Modèle Conceptuel de Données) n’avait jamais modélisé auparavant.

Mon approche n’est peut-être pas suffisante, mais en tout cas elle est nécessaire pour obtenir des relations de type PK/FK pertinentes.

[khena]

Excellent article ! A mon humble avis, et même si je suis entièrement d'accord avec tous les arguments, dans les PME, c'est principalement le problème de l'évolution des BDD après quelques années qui "refroidit" certains développeurs à créer les FK. Un mélange de "j'ai-pas-le-temps-de-code-ça-à-la-conception", "le-programme-ne-plante-pas" et de "je-peux-faire-ce-que-je-veux-quand-je-veux". Pas facile de les convaincre !

Je suis également contre (et là je suis sûr que des gens seront pas d'accord) le fait de faire des vérifications dans le code client EN PLUS de celles faites par la base de donnée. Par exemple si je veux supprimer un Produit, j'envoie directement un DELETE et je réagis sur l'exception, les vérifications préalables sont lourdes à écrire, couteuses en performance et au final peu rassurantes et difficiles à maintenir. Enfin c'est mon avis.

C'est un (autre) grand débat ! Tout à fait d'accord concernant les perfs, mais c'est surtout la gestion de tous les types possibles d'exceptions qui prend du temps. Par exemple, comment renvoyer à l'utilisateur que son insertion n'a pas fonctionné car : - la clé existe déjà ; - la connexion a été perdue ; - le champ est à blanc... selon le langage de programmation et de BDD, tu n'as pas de notions suffisamment précises pour détailler l'erreur de l'utilisateur (sans compter la gestion de la saisie par exemple...)
Sans compter que pleins de vilains développeurs n'aiment pas "voir" les exceptions , ce que je n'approuve pas plus que toi !

[fsmrel]

A noter qu'au paragraphe V-3 « La Loi, les règles de l'art », la paternité du modèle relationel est attribuée à Peter Chen : il s'agit d'une coquille, le garçon étant plutôt le père du modèle Entité/Association...

[_skip]

C'est un (autre) grand débat ! Tout à fait d'accord concernant les perfs, mais c'est surtout la gestion de tous les types possibles d'exceptions qui prend du temps. Par exemple, comment renvoyer à l'utilisateur que son insertion n'a pas fonctionné car : - la clé existe déjà ; - la connexion a été perdue ; - le champ est à blanc... selon le langage de programmation et de BDD, tu n'as pas de notions suffisamment précises pour détailler l'erreur de l'utilisateur (sans compter la gestion de la saisie par exemple...)
Sans compter que pleins de vilains développeurs n'aiment pas "voir" les exceptions , ce que je n'approuve pas plus que toi !

J'ai pris le cas d'un delete car c'est un exemple assez parlant, il faut souvent plusieurs requêtes pour vérifier qu'un enregistrement n'est pas utilisé, donc un grand bavardage réseau et au final, dans un environnement multi utilisateurs on peut tout à fait imaginer que le résultat positif de la 1ere requête ne soit plus valide à cause d'une insertion faite entre temps.

Donc les vérifications de ce genre sont coûteuses, superflues, peu rassurantes et multiplient l'effort de maintenance si la base de données évolue et s'agrandit de nouvelles tables et donc de nouvelles contraintes. Par ailleurs celui qui fait ça pour se passer de gestion d'erreur, je pense qu'il a tout faux.

Par contre attention, je n'ai pas dit qu'on pouvait pour autant se passer d'un minimum de validation en saisie que l'on peut renforcer au niveau sgbd par des contraintes NOT NULL, CHECK. Pour présenter les erreurs à l'utilisateur, c'est effectivement embêtant mais les codes d'erreur des drivers permettent le plus souvent d'indiquer des messages génériques style "Impossible de supprimer cet enregistrement car il est actuellement utilisé." Après c'est clair que si on veut du super détaillé, c'est plus difficile.

[SQLpro]

Par contre attention, je n'ai pas dit qu'on pouvait pour autant se passer d'un minimum de validation en saisie que l'on peut renforcer au niveau sgbd par des contraintes NOT NULL, CHECK. Pour présenter les erreurs à l'utilisateur, c'est effectivement embêtant mais les codes d'erreur des drivers permettent le plus souvent d'indiquer des messages génériques style "Impossible de supprimer cet enregistrement car il est actuellement utilisé." Après c'est clair que si on veut du super détaillé, c'est plus difficile.

Il est parfaitement clair que certaines contraintes sont immuables dans le temps. Exemple NOT NULL ou dates de borne d'une période dans le bon sens (debut<fin) sont des choses qui gagnent a être vérifier en amont car ce sera toujours vrai. Ce qui n'empêche pas qu'il faut les garder au sein du SGBDR car le jour ou l'on alimente les données par un autre tuyau que l'applicatif, ce sera la mort...
Le reste ne peut jamais être fait proprement que par le SGBDR !

A +

[khena]

Par contre attention, je n'ai pas dit qu'on pouvait pour autant se passer d'un minimum de validation en saisie que l'on peut renforcer au niveau sgbd par des contraintes NOT NULL, CHECK. Pour présenter les erreurs à l'utilisateur, c'est effectivement embêtant mais les codes d'erreur des drivers permettent le plus souvent d'indiquer des messages génériques style "Impossible de supprimer cet enregistrement car il est actuellement utilisé." Après c'est clair que si on veut du super détaillé, c'est plus difficile.

On est bien d'accord... ces deux sujets m'intéressent particulièrement, étant en phase de réécriture d'une grosse appli. C'est le moment où jamais de repartir sur un code propre!

L'utilisation des FK, avec tous les arguments cités dans l'article, tout comme celles des contraintes, permettent un gain de perfs assez conséquent et une certaine tranquillité d'esprit dans la cohérence des données. Mais le plus dur reste à venir : convaincre le reste de ma boite de les utiliser... Il suffit que je récupère les arguments de SQLPro en remplacant le mot "stupide" par quelque chose de plus soft La suite au prochain épisode !

[fsmrel]

Bonsoir,

Mais le plus dur reste à venir : convaincre le reste de ma boite de les utiliser...

C'est comme être mal assuré (voire pas du tout), ça coûte cher, après le pépin...

Quitte à me répéter... Vous avez encore quelques propositions de réflexion :

http://www.developpez.net/forums/d82...t/#post4720293

Et il n'est pas interdit de prototyper la performance des applications, cf. :

http://www.developpez.net/forums/d82...t/#post4711101

[SQLpro]

... Il suffit que je récupère les arguments de SQLPro en remplacant le mot "stupide" par quelque chose de plus soft La suite au prochain épisode !

On arrive vite du plus soft au consensus mou puis au politiquement correct ce qui conduit à la langue de bois... Bref, à pas grand chose !

A +

[fsmrel]

On arrive vite du plus soft au consensus mou puis au politiquement correct ce qui conduit à la langue de bois... Bref, à pas grand chose !

Peut-être, mais mettez-vous à la place de khena, il doit faire preuve de diplomatie... Et comme disat H.L. Mencken :

Quand un diplomate dit oui, cela veut dire peut-être.
Quand il dit peut-être cela veut dire non...
Et quand il dit non, cela veut dire que ce n'est pas un diplomate.

[Tofalu]

Salut,

Je viens de relire l'article et cette discussion ... et je suis surpris de ne pas avoir encore laissé de message... Un bon article comme toujours avec un ton que j'apprécie (n'en déplaise aux détracteurs. Quand quelque chose est stupide, il faut le dire )

J'ai un peu du mal à comprendre comment on peut passer à coté des FK et pire que certains justifient cela par un manque de temps ...
Les outils de générations crée cela automatiquement, n'importe quelle interface graphique permettent de les poser en deux clics voire moins et même au pire, s'il faut intervenir en SQL, c'est quand même pas la mer à boire que d'écrire une seule ligne.

Comme indiqué plus haut, on a eu le même débat sur le forum Access, et il faut voir les arguments de certains ... de l'inconscience

[_skip]

Pour access, tout comme windev ou autres environnements de développement L4G, les choses se laissent parfois faire tellement simplement que certaines personnes pas sérieuses peuvent obtenir des résultats sans obéir aux bonnes pratiques les plus basiques.
On s'en fout puisque ça marche, après tout c'est ce qui compte... Jusqu'au jour où...

Expérience que j'ai vécue avec un développement windev quand je débutais.

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