Discussion :

[vincent63]

Bonjour,

Je précise un peu le contexte qui me pousse à proposer ce sujet.

Je travaille sur une application client riche (CR) qui accède à une base Oracle qui nous sert de "panier de données". La logique métier se trouve entièrement sur le CR et dans la couche web, rien en base.

Le client (qui a à priori quelques connaissances en base de données) m'affirme que les contraintes sur la base : clés primaires, clés étrangères et tout le toutim sont inutiles puisque l'insertion en base et la cohérence entre les données est à priori gérée par la couche web.

Mon avis est que dans une base relationnel, il faut TOUJOURS (quand c'est possible évidement) définir des clés et des références pour garantir que les données sont TOUJOURS dans un état cohérent. Ce qui évite aussi les petites bévues liés aux manipulations directes en base lors des campagnes de tests.

Ces arguments n'ont pas l'air de l'émouvoir plus que ça et j'aimerai un retour d'expérience, l'avis de DBA ou autres, et peut-être des références de livres ou de documents qui argumentent en faveur de l'un ou de l'autre histoire que nous finissions par tomber d'accord.

En vous remerciant.

[Arturius]

Pour les clef primaires ne pas en mettre je trouve cela limite. De toutes manière tu vas être obliger de créer des index uniques ou non pour améliorer les performance. L'absence de clef primaire me parait limite.

Pour les clefs référentieles on n'est pas à l'abrit d'un TOAD connecté qui peut faire n'importe quoi sur les données.
Mais bon cela simplifie l'administration des tables de ne pas avoir de clef de référence. Maintenant dans 2-3 ans la doc ne sera pas à jour mais il sera troujours possible de comprendre le modèle de données à partir des FK .

De plus il y a plein de logiciels (requéteur ou autres) qui ce base sur les fk pour préparer les requêtes et comprendre le modèle de la base.

Les clef primaires les fk sont définis lors des specs et de la conception (normalment). Les développeurs ne maitrisent pas forcement la modélisation des données les fk et les clef primaire sont un bon support de développement. De plus un bug est si vite arrivé.

Je suis donc plutot favorable à la mise en place de ce type de contraintes.

[qi130]

La PK sert à identifier une occurrence parmi les autres. Si on n'en met pas, autant laisser tomber le SGBDR, un simple tableur suffit... Ton client pourra revendre son serveur...

Quant aux FK, le débat est ouvert.
Pour juger de leur pertinence dans ton contexte, il faudrait nous affranchir sur le "travail" réalisé avec cette base (insert ? update ? jointures ? etc...)

Cependant, si les perf sont correctes, autant conserver ces FK: elles ont le mérite de supporter un peu de logique applicative, tout en assurant un minimum de cohérence.

[vincent63]

Bonjour,

Merci pour les réponses.

En ce qui concerne le travail réalisé sur la base, on trouve effectivement des requêtes de sélection, de création, de mise à jour et de suppression. Les différents types de requêtes utilisent aussi des jointures sur les tables.

Et pour préciser encore d'avantage l'architecture utilisée, on a donc un client riche qui interroge la base et qui modifie certaines données en table (CRUD) et une application web qui elle gère une TRES grosse partie de l'alimentation en base. Autrement dit, sortir la gestion de cohérence de la base et l'extraire dans les clients revient à augmenter les sources potentielles de bugg.

Mais n'existe t-il pas de BEST PRACTICE sur la gestion de base de données qui indiquent clairement dans quels cas on PEUT supprimer les contraintes et dans quels cas on DOIT impérativement les garder?

[Xo]

Mais n'existe t-il pas de BEST PRACTICE sur la gestion de base de données qui indiquent clairement dans quels cas on PEUT supprimer les contraintes et dans quels cas on DOIT impérativement les garder?

Il y a plusieurs écoles : certains te diront qu'une BDD doit être "autonome", et que toutes la logique métier (contraintes, procédures et transactions) doit y être encapsulée, et d'autres qui ne font que gérer des données et préfereront déléguer la logique métier à un serveur d'applications dédié.

Je préfère la première solution, car tu ne seras jamais (tout à fait) à l'abri d'un utilisateur qui accédera en direct aux données, mais ça peut dépendre du contexte, des moyens, etc.

Le client (qui a à priori quelques connaissances en base de données) m'affirme que les contraintes sur la base : clés primaires, clés étrangères et tout le toutim sont inutiles puisque l'insertion en base et la cohérence entre les données est à priori gérée par la couche web.

Ca signifie quoi, "quelques connaissances en BDD" ? Prétendre que toute contrainte est inutile en arguant que c'est l'IHM qui s'occupera de l'intégrité me paraît assez désinvolte, voire dangeureux ...
Des contraintes, ça n'est pas coûteux à mettre en place et ça permet de contrôler pas mal de choses !

Dans le cas particulier des PK, comment gères-tu leur génération ? Via un auto-increment ? Ou tu laisseras l'IHM s'en charger ...

[SQLpro]

Bonjour,

Le client (qui a à priori quelques connaissances en base de données) m'affirme que les contraintes sur la base : clés primaires, clés étrangères et tout le toutim sont inutiles puisque l'insertion en base et la cohérence entre les données est à priori gérée par la couche web.

Non, il n'a aucune connaissance de ce qu'est un SGBDR !

Un SGBDR repose sur une logique mathématique ensembliste. Dans ces ensembles il n'y a donc aucune notion d'ordre pré établie. Si je vous donne une sac de bille et vous demande de me retirer la dernière vous serez infoutus de le faire. Le seul moyen est d'y ajouter l'information pour ce faire. C'est à dire une clef.

De la même manière l'absence d'intégrité référentielle conduit généralement à la pollution tôt ou tard de la base et à l'incompréhension de son modèle relationnel.

Clefs primaires et étrangères dont absoluement indispensables à l'élaborartion d'une base de données. De plus les contraintes de clef primaire induisent des index performants ce qui n'est généralement pas le cas d'index secondaire qui ne reposent pas sur une clef primaire.

L'inculture de votre client vient sans doute du fait qu'il à du abordé les SGBDR par des produits qui semblent en être mais n'en sont pas comme Access ou MySQL. Access est loin d'être un SGBDR et n'est même pas conforme à la norme SQL 1 de 1986 ! Quant à MySQL il ne s'agit nullement d'un SGBDR mais d'un gestionnaire de fichiers muni d'un vernis SQL qui donne l'illusion d'une bases de données relationnelle...
Il vaudrait miuex que votre client passe au Cobol. C'est ce qu'il y a encore de plus rapide en tant qu'accès fichier !

Hélas et c'est ce que je dis dans mes bouquins, la formation en France sur la théorie des SGBD et la langage SQL est si pauvre que l'on arrive à trouver des zozos en informatique qui sont capable par leurs positions démentes de scier la branche sur laquelle ils s'assoeint.
Rassurez vous c'est du pain bénit pour moi, car au bout de quelques années lorsque l'application a des performances lamentables, des gens comme moi doivent intervenit pour rectifier la sauce, avec des tarifs journaliers qui font plaisirs aux banquiers !!!
A moins que le quidma soit irrécupérable et constate que ledit SGBD ne tient pas ses promesses et décide de passer en mode full fichier...

A +

[fsmrel]

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 petits. 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 vie professionnelle, mais sans savoir qui elles étaient (coup de chance, c’était en pré-production...)

Etc.

Si le décideur veut apprécier objectivement, 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...)