Développement : la base de données, cette grande délaissée
26 juillet 2013
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
L’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.