Une base de données sans liens ni triggers

Utilisez-vous des liens entre les tables, dans vos développements ? Des liens déclarés au niveau de la base, comme par exemple l’intégrité référentielle ?

J’ai vu une application avec des dizaines de tables, sans aucun lien entre les tables. Tout est géré par le programme, y compris l’intégrité référentielle. A priori donc, sauf bug, il ne peut y avoir d’incohérence dans sa base.

Je n’ai aucun problème avec les notions présidant à la conception de base de données, mais je n’ai pas l’expérience d’un gros développement avec. Aussi je me demande si c’est la meilleure façon de coder une application qui se sert intensément d’une base de données.

J’essaie de voir le pour et le contre.

- Je suppose que la conception de la base (scripts de création des tables et scripts de mise à jour des tables) est plus simple comme cela, puisque que l’on ne se préoccupe pas de lien ou d’intégrité.
- Je me pose des questions sur les performances. Admettons que le programme ne soit pas bugué, n’obtient-on pas les résultats plus rapidement, en général, si l’on affiche des données d’une table parent et de sa table enfant, s’il y a déjà un lien au niveau de la base ?
- Est-ce que la gestion des erreurs n’est pas plus sure, si une violation d’intégrité référentielle est signalée par une exception générée par un trigger, au niveau de la base, plutôt que codée dans l’application ?

Bref, je suis un peu confus, là, car il me semblait naturel, jusqu’ici, de définir au moins les liens d’intégrité référentielle au niveau de la base.

Votre avis ? Merci de vos réponses :)

salut,

en ce qui concerne la définition de ta base de données, il est préférable à mon avis de définir les contraintres d'intégrités au niveau de tes tables car sur un plan de sécurité c'est beaucoup plus sur pour avoir une base de données cohérentes. de plus cela va éviter de faire des vérifications au niveau de ton code qui peux predre du temps si par la suite tu as une grosse base de données.

voiola ce que j'en pense

bon courage

C'est aussi ce que je pense, mais j'aimerais avoir des arguments plus solides à présenter...

Citation:

---

J’ai vu une application avec des dizaines de tables, sans aucun lien entre les tables. Tout est géré par le programme, y compris l’intégrité référentielle. A priori donc, sauf bug, il ne peut y avoir d’incohérence dans sa base.

---

C'est du crétinisme pur : sauf à utiliser massivement des transactions, le risque de toute coupure du poste client entraînera fatalement une désintégrité de la base. J'ai audité de nombreuses applications avec ce genre de connerie. Toutes se sont plantées. Tous on réalisé en catastrophe une moulinette pour vérifier l'intégrité. Sans penser que ce qui se fait directement dans un serveur est incommensurablement plus rapide qu'un traitement local avec des aller et retour entre serveur et client !

Citation:

---

Je n’ai aucun problème avec les notions présidant à la conception de base de données, mais je n’ai pas l’expérience d’un gros développement avec. Aussi je me demande si c’est la meilleure façon de coder une application qui se sert intensément d’une base de données.

---

C'est tout simplement la pire !

Citation:

---

J’essaie de voir le pour et le contre.

- Je suppose que la conception de la base (scripts de création des tables et scripts de mise à jour des tables) est plus simple comme cela, puisque que l’on ne se préoccupe pas de lien ou d’intégrité.

---

Tout simplement parce que les crétins qui réalisent de telles bases de données n'utilisent pas les outils adéquats et généralement ne savent même pas ce qu'est un modèle de données.
Avec un outil efficace de modélisation on ne touche JAMAIS directement la base. C'est l'outil qui le fait, même si le script SQL est complexe. Dont aucun problème de gestion des IR. Les gens qui arguementent comme tu le dit sont des ignares.

Citation:

---

- Je me pose des questions sur les performances. Admettons que le programme ne soit pas bugué, n’obtient-on pas les résultats plus rapidement, en général, si l’on affiche des données d’une table parent et de sa table enfant, s’il y a déjà un lien au niveau de la base ?

---

Tu as raison de te poser ces questions : les perfs ne peuvent qu'être médiocre parce que l'automatisation de la pose d'index, comme le calcul du plan de requête, et le plan résultant, concourreront à une moindre efficacité.

Citation:

---

- Est-ce que la gestion des erreurs n’est pas plus sure, si une violation d’intégrité référentielle est signalée par une exception générée par un trigger, au niveau de la base, plutôt que codée dans l’application ?

---

Elle est encore plus sûre, rapide et performante, s'il s'agit d'une IR interne, c'est à dire gérée par la base et non pas par trigger. De plus certaines options de gestion de l'IR sont très difficile à réaliser alors qu'au niveau de la création de la base il s'agit d'une simple option dans la définition de la contrainte.
A lire sur le sujet :
http://sqlpro.developpez.com/cours/s...e=partie2#L7.3

Citation:

---

Bref, je suis un peu confus, là, car il me semblait naturel, jusqu’ici, de définir au moins les liens d’intégrité référentielle au niveau de la base.

---

Oh que oui, sans aucune exception, si ce n'est celle de l'ignardise crasse. Et en cette matière le manque de formation a SQL, aux principes des SGBDR et à la modélisation des données est hélas de plus en plus catastrophique en France !
Ton interrogation est révélatrice de la lourdeur des imbécilités qui circulent parfois dans le milieu informatique...

A +

Lu,

Je suis confronté a ce "probleme" actuellement.
Le chef de projet, n'aime pas mettre des clefs etrangere dans ses modeles de base de données.
C'est la premiere remarque que j'ai fait quand j'ai voulu attaquer sa base avec ReportNet.
En effet, les outils de ce genre, se servent de ces informations pour importer le modele.
Du coup là je dois les faire depuis ReportNet, alors que ça devrait être géré automatiquement, et surtout en accord parfait avec les choix de modelisation du concepteur.

L'argument qu'il invoque c'est que Oracle gueule lors du chargement des tables.

Comment doit on s'y prendre pour faire ça dans les regles de l'art ?

Je suis confronté à ce probleme aussi...
Mon application se greffe sur la base de données de l'ERP maison. C'est une base avec environ 400 tables, pas de doc (la transmission du savoir est orale comme pour les légendes dans les peuplades primitives...), pas de clés etrangères ou contraintes d'intégrité, donc pas d'outils de reverse fonctionnant correctement...
De plus comme ils n'utilisent pas de champs unique pour servir de clé dans certaines tables, on arrive à des abbérations du genre 11 champs dont 9 dans la clé primaire et un pour la date de modif...
Rien que pour les gens qui seraient amener à developper autour de ta base pour la suite, utilise des clés étrangères et contraintes....

Citation:

---

Envoyé par mirak63

L'argument qu'il invoque c'est que Oracle gueule lors du chargement des tables.

Comment doit on s'y prendre pour faire ça dans les regles de l'art ?

---

Il faut, au choix:

- soit charger en 1er les tables référencées
- soit lever temporairement les IR

Citation:

---

Envoyé par qi130

- soit charger en 1er les tables référencées
- soit lever temporairement les IR

---

Si Oracle "Gueule", c'est qu'il a de bonnes raisons, j'ajouterais donc à ta liste :
- Charger des données cohérentes ! Et justement ORACLE avec IR déclarée, vérifie que les données sont cohérentes :
ORACLE 1 "Le chef de projet qui n'aime pas mettre des clés étrangères " 0.

Les contraintes d'intégrité sont absolument effectivement indispensables dans les SGBDR dans le cas contraire on se retrouve avec une base de plus en plus bancale.

Les causes de ce refus des contraintes d'intégrité peuvent effectivement provenir d'une méconnaissance grave de la modélisation et des bases des SGBDR.

Mais je vois deux autres causes.

Certaines personnes proviennent du monde des gros et moyens systèmes et ont aucune idée des contraintes d'intégrité des SGBD Relationnels et en fait appliquent les méthodes des bases de données hiérarchiques. Ce style de base est trés loin des SGBDR mais si les personnes sont compétentes en base de données hiérarchiques ce genre de base tient pas trop mal la route malgré que ce soit une hérésie du point de vue des SGBDR, et que l'intégrité de ces bases sera tout de même très dur à mainternir.

Une autre cause beaucoup plus grave provient du fait que l'expression des besoins a été baclée ainsi que la modélisation au sens large du terme. Autrement dit plutôt que de faire des efforts pour que la modélisation soit conforme aux demandes des utilisateurs, les tables sont conçues en dépit du bon sens, et des colonnes sont rajoutés au petit bonheur la chance de temps en temps sans vue d'ensemble. En fait ce n'est pas tant le fait que les tables ne soient pas normalisées c'est surtout que tout le travail en amont des besoins fonctionnelles des utilisateurs a été complétement éludé.
Donc évidemment dans ce cas les contraintes d'intégrité ne font pas long feu car tout les jours un cas non prévu remettra en cause ces contraintes.

edit:

Citation:

---

Envoyé par christopheJ

Mon application se greffe sur la base de données de l'ERP maison

---

Les ERP (ou autres CRM) sont le plus souvent des cauchemards que cela soit du point de vue de la normalisation que des contraintes d'intégrité...sans parler du typage des données. Tout cela pour s'économiser du temps de développement, et de maintenance évolutive, spécifique à chaque plateforme et accessoirement pour rendre leur modèle incompréhensible.

Bien, merci de toutes ces réponses qui me rassurent quant à ce que je pensais : il vaut mieux définir ces contraintes au niveau de la base. Et ce d’autant plus que j’ai appris depuis que des techniciens de maintenance font parfois des interventions directes sur les tables, manuellement, et donc sans aucune garantie de cohérence dans les données…


Bon... Une appli sans documents de spécification, sans doc technique (pas de commentaire dans le code), programmée sans analyse (UML? Who needs that?), sans tests (il y a les clients pour cela), sans outil de debugage (à part celui intégré dans Delphi) et bien sûr sans contrôle de version...


Je sens que j'ai du travail....

Citation:

---

Envoyé par qi130

- soit charger en 1er les tables référencées

---

En fait sur le diagramme il y a des dependeances circulaires, donc là ça risque d'etre dur :roll:
:D

hum bizarre son schema :?
Y a deux tables A et B qui sont reliées par leur propres clef primaires !!!
A moins qu'il est voulu faire un heritage je vois pas trop l'interet.
Ah ouf, apparement c'est ça lol

La gestion des heritages en sgbdr c'est quand même pas joli.
Avec des vues ça peut etre moins crade a l'utilisation, mais bon au niveau du model :?

mmm en fait je pense qu'il a du avoir des problemes quand une table à un clef étrangere qui pointe sur ça propre clef primaire.
Si les données sont pas chargées dans l'ordre ou si il y a un chainage circulaire, c'est coincé.

Bref je lui dirais qu'il peut desactiver les contraintes :)

J'ai trouvé un "livre blanc" qui dit grosso modo le contraire de l'opinion générale dans ce sujet, autrement dit qui dit que les règles d'intégrité référentielles devraient être traitées comme des règles métiers, et pas dans la base de données. Le cadre de ce livre blanc est la conception d'un couche d'accès aux données à travers des objets.

Autre chose de troublant, c'est la suggestion d'abandonner, pour la création des clés, les données métier et d'utiliser que des GUIDS. Voici un extrait :

Citation:

---

Vous pouvez remarquer que la table Customer dans la figure précédente contient un champ qui n’a aucun équivalent dans le modèle objet. Il s’agit de la clé primaire : ID. Ce champ est de type GUID (General Unique Identifier), et représente de manière unique un enregistrement dans une table. Si par le passé vous définissiez vos clés primaires comme un ensemble de champs métiers de chaque table, c’était dans l’optique d’insérer une contrainte d’intégrité, et par exemple de confier au serveur de base de données la tâche de vérifier que deux enregistrements représentant la même entité logique ne puissent être insérés. Cette règle est typiquement une règle métier qui pourra être incluse dans la couche d’accès aux données, renvoyant une exception caractéristique par exemple. Dans l’optique de l’utilisation d’une couche d’accès aux données, les clés doivent être uniques, et n’avoir aucun sens vis-à-vis du métier qui est modélisé. Dans cette optique, les GUID sont la solution idéale.

---

Que pensez-vous de tout cela ?

Les références circulaires ne sont pas un problème si le SGBDR considéré implémente la notion de déférabilité des donctraintes comme POSTGRESQL le fait.

Sur le livre blanc et son optique d'IR non géré par le serveur qui trouble notre ami Promeneur...
1) le mapping relationnel objet est la suite de l'abandon des SGBDOO qui ont fait long feu. C'est une technique intéressante mais peu utilisée.
2) dans tous les cas elle suppose un outil de gestion de la persistance qui remplace ou se supperpose à l'IR, donc ajoute une couche de complexité et diminue les performances. (Et à quel coût !)
3) l'utilisation d'un identifiant de type GUID est particulièrement contre performant par rapport à un entier taillé sur la longueur du mot du processeur (16 octets pour le GUID contre 4 pour le INTEGER, c'est donc plus de 4 fois moins rapide).

Pour ma part mon expérience de l'objet dans le domaine des SGBD remonte à O² en 1993... Et depuis, rien de nouveau sous le soleil, c'est lourd, long, peu performant et encore mal maitrisé.

je rajouterais pour terminé qu'une entreprise que je ne nommerais pas pour lui éviter une mauvaise publicité vendait ce concept de clef transversal unique au sein de toute la base en s'absolvant de la notion SQL d'IR et en le faisant par du code. C'était horriblement contre performant et comme la persistance était peu ou pas gérée, cela merdait à plein tube. Lorsque je suis allé auditer des applis avec ce genre de singerie c'était un régal... Et le client qui avait payé fort cher (beaucoup plus que la version classique) son dev, redevait payer pour la modif, car l'entreprise se retranchait derière des spécif allucinante du genre ; RAID 5 partout, onduleur ONLINE partout, cluster...

A +

Bien qu'étant d'accord a priori avec SQLpro je voudrai juste faire remarquer que mysql ne supportait pas jusqu'à il n'y a pas longtemps, sauf erreur de ma part, l'intégrité référentielle.
Je crois même que c'était un argument très fort justifiant les performances de cette base !!
Aussi, même si je pense qu'il faut généralement faire gérer l'IR par la base, je ne serai pas catégorique comme l'ai SQLpro car des usages d'une base comme mysql risqueraient d'apporter de bons arguments contre la gestion de l'IR par la base....méfiance donc

OK merci pour ces intéressantes réponses !