Coucou tout le monde !
Aujourd’hui je voulais écrire un petit billet sur les différentes façons de gérer l’intégrité de sa base de données.
L’intégrité dans une base de données
Avant toute chose, il est bon de rappeler à quoi correspond l’intégrité des données dans une base de données. Je me place volontairement dans le cas des SGBD relationnels. Pour cela, rien ne vaut une petite citation made in Wikipédia :
L’une des missions d’une base de données est d’assurer à tout instant l’intégrité, c’est-à-dire la cohérence, la fiabilité, et la pertinence des données qu’elle contient.
Pour faire simple, chaque donnée contenu dans vos tables doit être pertinente et à jour ! Et cela quelque soit les manipulations faites sur votre base. Suppression, mises à jours, insertions …
Cas concret de perte d’intégrité
Prenons le cas d’un forum. Il existe une table “topic” et une table “message”. Pour lier les deux tables, on rajoute une colonne dans la table “message” faisait référence au topic auquel appartient le message.
Cependant qu’arrive-t-il quand je supprime un topic ? En effet, des messages y sont certainement liés, et si c’est le cas ils doivent être supprimés ! Dans le cas contraire on se retrouve avec des messages orphelins et l’intégrité (référentielle) de la base de données est perdue.
Problématique
C’est alors pendant la phase de conception de notre projet, que l’on doit se demander qui doit assurer l’intégrité de la base de données.
Deux solutions
A ma connaissance il existe deux moyens de faire respecter l’intégrité de votre base de données :
- Créer une couche d’abstraction dans votre application qui gère l’intégrité : Framework avec ORM généralement.
- Créer des contraintes d’intégrité directement dans la base de données à l’aide du SGBD.
Côté applicatif
Il est tentant pour le développeur de vouloir gérer l’intégrité de sa base directement dans son code source. En effet, on gagne en flexibilité, on pense savoir se que l’on fait, on rajoute une couche d’abstraction et puis c’est fait main donc on maîtrise tous les aspects.
On peut aussi se retrouver à utiliser un Framework qui propose de s’occuper de l’intégrité des données pour peu que vous le configuriez comme il faut. C’est tentant, la partie fastidieuse du code est déjà faite, on vous propose quelque chose de générique et bien construit, et puis essayer de le configurer vous aidera à mieux maîtriser ce Framework.
Cependant l’expérience tend à me faire dire que c’est une solution dangereuse. Il y a des risques majeurs :
- En multi-développeurs : un seul développeur oublie de configurer les contraites et c’est le drame.
- Si d’autres applications veulent accéder à la base de données, elles sont obligées elles aussi de gérer l’intégrité dans leur code et de la même façon.
- En cas de refactorisation du code, on peut supprimer des contraintes par mégarde et les tests auront du mal à le déceler.
Un des rares avantages de cette méthode est qu’elle centralise toute la partie logique/métier du projet au même endroit du projet. De plus, on évite de toucher à la base de données car pour certains ce n’est pas leur cheval de bataille.
Côté SGBD
Ici on utilise la puissance du SGBD pour qu’il garde lui même l’intégrité des données sur ses tables. Chaque SGBD a ses méthodes, mais de façon général on utilise :
- Les clefs étrangères pour faire respecter les contraintes d’intégrités référentielles.
- Les triggers : suppressions, modifications en cascade.
Tous c’est outils assurent de manière forte et pérenne l’intégrité de la base de données.
L’inconvénient majeur est qu’à chaque ajout ou modification d’une table, il faut manipuler le SGBD pour rajouter ou mettre à jour des contraintes d’intégrités. Malheureusement ce n’est pas le dada de tout le monde de passer du temps en base de données.
Cependant l’avantage est indéniable : nous n’avons plus rien à faire côté applicatif, on récupère juste le cas échéant une erreur du SGBD pour violation de contrainte. De plus en terme de maintenabilité on est tranquille en cas d’évolution du code ou de changement de développeur : le SGBD veille au grain.
Conclusion
La conclusion de cet article se résume en une seule phrase :
Gérer l’intégrité de votre base de données directement dans votre SGBD !
J’ai pas vraiment compris : quand tu parles d’opérations sur la table, c’est Insert/Update/delete de lignes ou de modification de la structure de la table (ajout d’un champ, etc …) ?
Parce que justement, avec les triggers tu peux faire en sorte de supprimer les lignes qui référençaient celle supprimée.
Concernant l’ORM je me demande si cette solution fonctionne vraiment. A chaque fois que j’ai fait du web, déclarer la structure de la table dans un ORM (comme celui de Django), c’est en fonction de ce que tu as mis en BDD, y compris les contraintes d’intégrité.
Je parle bien de modifications de la structure de la table. Si tu renommes une clef étrangère, il peut être nécessaire de mettre à jour des triggers ou autre…
Pour l’ORM ça dépend du FrameWork que tu prends. Certains offrent des solutions clefs en main, d’autres sont moins fournis. Cependant tu peux très bien ne faire aucunes contraintes d’intégrité en base, et les coder en dure dans tes sources. Je ne recommande évidemment pas cela, comme dit dans mon article.
Enjoyed studying this, very good stuff, regards . A man may learn wisdom even from a foe. by Aristophanes. dgfecbkaaecbbbed