Discussion :

[Exsilius]

Ma question est peut-être idiote et j'avoue avoir eu du mal à vérifier si la réponse exister dans les tutos ou les forums puisque le problème est assez général...

J'ai des tables 'Bibliothéques' vers lesquelles pointent la plupart de mes autres tables. Par exemple, une table 'Text' pour gérer le multilinguisme, avec laquelle tout mes champs ayant une string devrait avoir une relation.

Je dis devrais car je me demande dans quel mesure cela est pertinent :
Si je fais toutes mes relations, je pourrais gérer les suppression en cascade, etc..., mais je me pose la question des performances...

Qu'en pensez vous ?

[Xo]

Qu'en pensez vous ?

Que ta question est un peu vague : j'ai l'impression que tu mélanges la modélisation, la technique (règles de gestion des données) et les performances.

En supposant que ce soit un problème de modélisation, il faudrait nous donner un aperçu un peu plus exhaustif de ton modèle.

Pour la suppression d'un enregistrement, il faut gérer cela via une transaction, en testant bien entendu la présence d'enregistrements fils.

Au passage, ce thread devrait t'intéresser quant à ton interrogation sur la normalisation : entre la theorie et la pratique!

[Exsilius]

Effectivement, je ne situe pas précisement la question.

Il s'agit d'une question purement technique - lié au performances.

Dans mon modèle logique mes relations existent bien évidemment.
Au niveau de mon modèle physique, je me demande si j'ai intérêt à créer ces relations dans la base de données (comme toutes les autres relations), ou bien s'il y aurait un intérêt technique à le gérer dans ma couche d'accés aux données (par exemple).

La question pourrait-être plus simplement :
Y a t'il des cas ou une relation dans le modèle logique ne se matérialise pas dans la base de données ? Et si oui, dans quels cas ?

Suis-je plus clair ?

[Xo]

La lecture de ce (long) post devrait t'éclairer : SI & SGBD : comment/où gérer les règles métier ?

[Exsilius]

euhhhh..... C'est un bizutage, ou bien ?

J'ai tout de même eu le courage d'en lire une bonne partie, mais je t'avoue que, outre le fait d'y lire une certaine joute verbale (pour ne pas dire verbeuse) entre 2 experts SGBDR aux approches différentes, je n'ai pas eu l'impression (ou pas su trouver ?) les infos qui me concernent...
[A moins de lire le bouquin de 130 pages qui est conseillé, mais je t'avoue que ça me fait mal, pour une question d'optimisation ]


Il y a bien l'intervention de Fadace, mais elle m'ait trop imprécise

Je suis quant à moi pour la solution mixte (c'est bien Suisse, ça !) : les règles complexes via le 2e tiers, et l'intégrité "de base" dans ... la base, préservant au moins ce qui peut l'être...

...

[fsmrel]

Bonjour Exsilius,


Vous avez écrit

Si je fais toutes mes relations, je pourrais gérer les suppressions en cascade, etc..., mais je me pose la question des performances...

Comme dit Xo, vous mélangez les niveaux. Vous dites que ce sont les performances qui vous intéressent au premier chef. Si dégradation de performance il y avait à mettre en œuvre l’intégrité référentielle, à nous d’être assez intelligents et compétents pour faire en sorte que cela reste imperceptible. Prenez-vous par la main, et faites un prototype. Si ça n’est pas de votre ressort ou dans vos compétences, faites-le faire par un DBA qualifié. D’expérience, je n’ai jamais eu à supprimer les liens d’intégrité référentielle, mais parce que j’ai pris la peine de vérifier qu’ils n’avaient pas d’impact sur la performance, ou si peu (Bases de données de plus de 1000 tables avec pour certaines d’entre elles des dizaines de millions de lignes). Maintenant, vous trouverez toujours un incompétent pour affirmer le contraire, auquel cas il serait bien que celui-ci apprenne véritablement le métier plutôt que colporter des légendes.

Vous trouvez comme intérêt à l’intégrité référentielle la possibilité qu’elle offre en matière de suppression en cascade : ceci est évidemment bien intéressant, mais vous n’avez pas compris ce qui fondamental : la validité du contenu de la base de données. Maintenant, si vous voulez touiller de plus en plus vite des données non valides, supprimez les liens d’intégrité.

Je reprends un message que j'ai envoyé à Vincent63 :

L’intégrité garantie par le SGBD c’est quand même la sécurité (ceinture, bretelles et épingle à nourrice.)

J’ai connu une société d’assurance qui ne mettait pas en œuvre l’intégrité référentielle, puisque l’application prenait tout en charge. Dans un contexte de transfert de données vers une autre application, on a constaté qu’il y avait 40% d’orphelins => un an pour essayer de retrouver les liens entre les lignes des tables parentes et enfants. L’incantation et la crédulité peuvent mener loin...

Un marchand d’automobiles : des milliers de contrats sans clients en face...
Dans le monde de la retraite : 700 000 personnes pour lesquelles on n’avait plus que l’historique de leur carrière mais sans savoir qui elles étaient (coup de chance, ça n’était qu’en pré-production...)

Etc.

Si le décideur veut apprécier objectivement, alors qu’il mette en œuvre les contraintes d’intégrité "pour voir", apprécie et les enlève ensuite si ça lui chante. Ça n'est pas en assenant "C'est inutile !" que l'on prouve quoi que ce soit... Ignoratio elenchi.

De toutes façons, à supposer que l'application s'occupe de tout, ça reste transparent de mettre en oeuvre clés primaires, étrangères, etc., ça reste sous le capot (aux tests des codes-retour près...)

http://www.developpez.net/forums/sho...d.php?t=241850

J'espère qu'un jour vous comprendrez que ce que vous tenez pour un bizutage vous sera de quelque utilité. Paris ne s’est pas fait en un jour. Au demeurant, les experts peuvent ne pas être d’accord sur tout, mais sur l’essentiel ils arrivent à se rejoindre.

[Exsilius]

Que de condescendance et de jugements plus-que hatifs...

Vous trouvez comme intérêt à l’intégrité référentielle la possibilité qu’elle offre en matière de suppression en cascade : ceci est évidemment bien intéressant, mais vous n’avez pas compris ce qui fondamental : la validité du contenu de la base de données. Maintenant, si vous voulez touiller de plus en plus vite des données non valides, supprimez les liens d’intégrité.

Malgré ma modeste expérience du monde des SGBDR, je connais un tant soi peu l'intérêt de l'intégrité référentielle, au point qu'il me paraisse inutile d'en parler dans la présentation de ma problèmatique - le but des forums étant la concision et la rapidité [...].

Il est bien évidemment préférable de gérer mes relations dans la base de données - quant bien même il est techniquement largement faisable de l'effectuer dans les couches basses de l'appli (les bases de données existaient avant les SGBDR).
Au niveau logique je n'ai pas de problème avec mes relations.
Au niveau physique, je voulais savoir quelles contraintes, un grand nombre de relations peut amener.

Vous avez répondu, puisque je crois comprendre qu'à ma question : "Doit-on créer toutes les relations ?" votre réponse aurez pu être : "D'aprés moi, oui. Les problèmes de performances sont de faux problèmes et peuvent être contourner".
Et je vais donc taguer cet discussion de résolu à mois que d'autres n'aient une opinion différente où, dans certains cas, il leur semble justifié de ne pas implémenter certaines relations dans la base.

J'espère qu'un jour vous comprendrez que ce que vous tenez pour un bizutage vous sera de quelque utilité. Paris ne s’est pas fait en un jour. Au demeurant, les experts peuvent ne pas être d’accord sur tout, mais sur l’essentiel ils arrivent à se rejoindre.

Au demeurant, je vous remercie donc sincérement pour vos conseils d'expert sur le plan technique.

De mon côté, si vous me permettez de vous rendre la pareille sur un autre plan (ou je n'oserais me qualifier d'expert) :

"L'esprit du débutant contient beaucoup de possibilités, mais celui de l'expert en contient peu"

Je pense que l'on peut avoir beaucoup d'expérience, tout en gardant l'humilité de se rendre compte que nous savons si peu face au Tout...
Je pense qu'un véritable expert garde l'esprit du débutant. Pour continuer à progresser et pour savoir transmettre.

Encore merci pour votre aide,
Amicalement.

[fsmrel]

Bonsoir,

Il est bien évidemment préférable de gérer mes relations dans la base de données - quant bien même il est techniquement largement faisable de l'effectuer dans les couches basses de l'appli (les bases de données existaient avant les SGBDR).

Soyez rassuré, j’ai longtemps transpiré sur quelques SGBD pré-relationnels, qu’ils s’appellent IMS/DL1, IDMS, Total, Adabas. Concernant les relations, je suppose que vous voulez faire allusion aux pointeurs permettant de naviguer d’un objet à l’autre (pointeurs Physical Child, Physical Parent, Physical Twin, Logical Child, etc. de DL1, Next, Owner, Prior de Codasyl, et j’en passe). Le problème est que ce ne sont pas ces pointeurs qui garantissent qu’en face d’un contrat il y a toujours un client, ou une facture en face d’une ligne de facture. Rien ne vaut une bonne expression simple du genre "Foreign key (colonne clé étrangère) References table parente", exprimée au niveau logique, plutôt qu’au niveau physique ou pire, au fin fond des applications (comme je l’ai déjà vu faire, ce qui est problématique quand le développeur a eu la quille depuis belle lurette et n’a rien documenté). Concernant la relation — ou plutôt l’association — entre objets, quand il s’agit de manipuler des tables, rien ne vaut une bonne jointure, l’opération relationnelle par excellence.

Au niveau physique, je voulais savoir quelles contraintes, un grand nombre de relations peut amener.

Je répète ce que j’ai dit plus haut : d’expérience, je n’ai jamais eu à supprimer les liens d’intégrité référentielle, dans un contexte de production, mais parce que j’ai pris la peine de vérifier concrètement qu’ils n’avaient pas d’impact sur la performance, ou si peu (Bases de données de plus de 1000 tables avec pour certaines d’entre elles des dizaines de millions de lignes). Observer, mesurer, démontrer, encore démontrer, sinon l’on n’est pas crédible.

Les contraintes prévisibles sont plus à craindre au niveau de l’organisation de la production informatique, quand il s’agit de procéder à des sauvegardes cohérentes des données. Il s’agit d’un chantier à part entière, impliquant les DBA et la Production, et là, je suis d’accord, il faut être particulièrement vigilant.

votre réponse aurez pu être : "D'aprés moi, oui. Les problèmes de performances sont de faux problèmes et peuvent être contourner".

Vous ne m’avez pas compris. J’ai dit qu’il ne fallait pas tout traiter en même temps. On modélise (niveau conceptuel), puis on dérive les entités-types et relations-types sous forme de tables et de contraintes au niveau logique, puis au niveau physique on choisit et met en œuvre les table spaces pertinents, les index et autres éléments concourant à la performance. Maintenant, il est évident que si on n’a pas en arrière-plan dans sa tête la dimension performance, quel que soit le niveau où l’on se situe, alors on peut s’attendre à de bien cruelles désillusions. D’où la nécessité de monter des prototypes de performance très rapidement. Sachez que j’ai passé mon temps à engager mon entreprise (une SSII) auprès de nos clients sur ce plan très délicat et sensible : je suis le dernier à prétendre qu’il s’agit d’un faux problème.

"L'esprit du débutant contient beaucoup de possibilités, mais celui de l'expert en contient peu"
Je pense que l'on peut avoir beaucoup d'expérience, tout en gardant l'humilité de se rendre compte que nous savons si peu face au Tout...
Je pense qu'un véritable expert garde l'esprit du débutant. Pour continuer à progresser et pour savoir transmettre.

Quelque part, je vous ai choqué et j’en suis désolé. N’allez surtout pas croire que j’ai la prétention de tout savoir ! Au contraire, plus le temps passe et plus on comprend son sujet, plus on a conscience de ses lacunes. J’ai encore de la marge en termes de progression et c’est tant mieux, sinon j’arrêterais tout. Maintenant, pendant toutes ces années, je ne suis pas resté les deux pieds dans le même sabot, j’ai beaucoup crapahuté dans bien des domaines, en particulier dans celui des bases de données et j’ai capitalisé, monté bien des cours, beaucoup enseigné et j’ai été très heureux quand mes élèves purent à leur tour concevoir l’architecture de bases de données robustes et performantes. Même quand ces élèves faisaient partie de sociétés concurrentes et que ma mission initiale n’était pas de leur enseigner quoi que ce soit mais d’expertiser leurs travaux.

Ce qui est sûr, c'est que les sujets importants sont beaucoup plus délicats à aborder sur un forum comme celui-ci : c’est quand même dans un dialogue en tête-à-tête que l’on résout au mieux les problèmes et que s’installent la compréhension et la confiance mutuelles. Faisons avec les moyens du bord...

[Exsilius]

Je pense avoir eu largement la réponse à ma question.

Je ne comprends pas ce que vous entendez lorsque je parle de relations.
Les éléments que vous citer (pointeurs Physical Child, Physical Parent, Physical Twin, Logical Child, etc. de DL1, Next, Owner, Prior de Codasyl) me sont parfaitement inconnus, je parlais effectivement de relations mis en évidence au niveau conceptuel (et effectivement, par exemple, issus de clés étrangéres). Etant auto-didacte sur de nombreux points, ma terminologie est sans doute approximative et issu pour partie, des logiciels que j'utilise.

Quoi qu'il en soit, merci d'avoir pris le temps de répondre largement à ma question, et bonne continuation.