Développement : la base de données, cette grande délaissée

C’est avec l’augmentation de la volumétrie des données associées à une application qu’apparaissent très souvent les problèmes. La base de données est alors incriminée alors qu’elle aura tout simplement été négligée par les développeurs qui croient, à tort, par le code pouvoir tout prendre en charge. La base de données doit être traitée de manière autonome. L’une des arguties principalement utilisée par des développeurs souvent incompétents en matière de base de données est d’évoquer la complication à changer de moteur. C’est tout simplement l’inverse. En rendant la base de données autonome, vous n’aurez pas à toucher à une seule ligne de code.

Clés et index

La base de données, cette grande délaisséeL’un des principes de base des moteurs de base de données est que le parcours des données – comme celui de livres – est plus rapide au travers d’index posés sur les champs utilisés dans les recherches. A défaut, la lecture des pages de données s’effectue avec la clé.

Contraintes d’intégrité référentielle

L’intérêt du modèle relationnel est de minimiser l’espace consommé par le stockage des données en éclatant l’information stockée dans différentes tables liées par des contraintes d’intégrité référentielle. Vous ne pourrez ajouter une référence dans une table « enfant » qu’à la condition qu’elle existe préalablement dans la table « parent ». L’intérêt de ce mécanisme est de permettre la mise à jour et la suppression en cascade. Pour la suppression, il convient évidemment d’être extrêmement prudent. Au cas où le nombre de lignes de la table « enfant » est plus faible que la table « parent », il peut être intéressant que la relation soit pilotée par un index posé sur la clé étrangère de la table « enfant ».

Contraintes d’unicité

C’est sans doute l’un des éléments les plus intéressants pour le développeur. Plutôt que d’effectuer un SELECT à chaque insertion ou mise à jour, il vaut mieux intercepter l’erreur provoquée par l’instruction INSERT. C’est beaucoup moins coûteux que d’effectuer des SELECT qui finissent par être consommateurs de ressources tant au niveau du CPU par répétition des accès au disque qu’au niveau du cache de la base de données.

Check Constraints

A l’exception de MySQL (1), les principaux moteurs de bases de données – Oracle, DB2, SQL Server, PostgreSQL, Firebird, Ingres – permettent d’utiliser des contraintes de validation. Plutôt que de pisser de la ligne de code très inutilement, il suffit une fois encore d’intercepter l’erreur et de la traiter dans le code.

Triggers

Les triggers ou déclencheurs permettent avant tout de libérer l’application très rapidement. En mode transactionnel, ils permettent une gestion asynchrone des traitements. La seule limite est d’évaluer, dans le cadre d’une application qui procède à l’acquisition de données en temps réel, si le temps de traitement des données par trigger peut constituer un goulet d’étranglement potentiel par rapport à un traitement multi-thread réalisé au niveau de l’application.

Vues

En factorisant les requêtes par la constitution d’un catalogue de vues, vous permettrez très souvent au moteur de base de données d’économiser de la mémoire consommée en optimisant le cache utilisé. C’est un des éléments qui est hélas totalement négligé.

Procédures stockées

Appelées à partir des applications ou planifiées dans les moteurs, elles permettent de réaliser des traitements asynchrones. L’utilisation de curseurs minimise la consommation des ressources consommées dans le cadre de la manipulation d’un grand volume de données.

(1) Gageons que MariaDB nous offre très bientôt la possibilité de poser des contraintes de validation.

Base de données  / Bases de données Formateur Bases de données Formateur MariaDB Formateur MySQL Formateur PostgreSQL Formateur SQL Server Sgbd Sgbdr 

Commentaires

Bonjour,

Tout à fait d’accord ! Il est très important de bichonner sa base de donnée, bien utilisée elle permet de gagner des lignes de codes et des heures de débogage.

Je pinaille sur l’article, mais le moteur InnoDb MySQL permet de mettre en place des contrôles d’intégrité dans la structure de la base. Lorsque MySQL ne permet pas les contrôles d’intégrité, c’est généralement que la base est configurée avec le moteur MyIsam (le moteur historique).

Bonne continuation sur cet excellent blog !

@MrBidon

Bien sûr qu’en InnoDB, MySQL permet les contraintes d’intégrité référentielle. Je parle des CHECK constraints !

Laisser un commentaire

(requis)

(requis)