Quel SGBDR choisir ? Prise en charge des applications et critères d’achat
En plus des forces et faiblesses des SGBDRs, deux autres facteurs influent sur le choix d’une base : la prise en charge des applications et les critères d’achat.
Cet article fait suite à l’analyse des forces et faiblesses des SGBDRs. Il revient sur deux autres facteurs de choix d’une base relationnelle : la prise en charge des applications et les critères d’achat.
Problématique de la prise en charge des applications
Lors de l’évaluation d’un SGBD, n’oubliez pas de vous poser cette question : comment les bases de données vont-elles prendre en charge vos applications ? S’agit-il d’applications comportant des transactions classiques ou des traitements par lots ? Ou bien développez-vous des applications 2.0 ? Prenez-vous en charge l’IoT ?
La majeure partie des applications traditionnelles de gestion et d’analyse des données, notamment celles de traitement transactionnel (OLTP) et de traitement par lots, celles aux charges de travail mixtes et d’informatique décisionnelle, se prêtent bien à l’utilisation de bases de données relationnelles.
D’autres situations spécifiques incitent à privilégier le modèle de données SGBDR : si les définitions et la structure des données sont cohérentes ; lorsque l’intégrité et la précision des données doivent être immédiates ; et pour le traitement des types de données traditionnels comme les chiffres, les dates et les valeurs alphanumériques.
Il est conseillé d’adopter en standard un SGBD relationnel et de s’en écarter uniquement pour les projets qui ne tirent pas d’avantage des fonctionnalités relationnelles actuelles, par exemple les projets Web 2.0, la diffusion de données en streaming et l’analytique du Big Data dont les schémas ne sont pas figés.
Critères d’achat d’un SGBDR
Lors de l’achat d’un système de base de données, quel que soit son type, différents critères standard sont à prendre en compte pendant la procédure d’appel d’offres et la période d’évaluation.
D’abord, l’architecture du SGBD et son adéquation aux projets. L’architecture du SGBDR convient à la plupart des besoins de gestion des données, mais peut poser problème dans les projets impliquant des schémas flexibles ou des relations complexes entre éléments de données.
Prenez également en compte la disponibilité et la robustesse des fonctionnalités d’administration des bases de données. Ainsi, la sauvegarde et la restauration, la gestion des changements et des performances constituent des fonctions d’administration essentielles. Les produits SGBDR sont bien dotés à cet égard. Il existe également de nombreux modules complémentaires.
Le déploiement, notamment les conditions d’installation, les prérequis matériels et logiciels et les fonctionnalités de virtualisation, est un aspect à ne pas négliger non plus. La majorité des SGBDR propose des procédures et des fonctionnalités solides dans chacun de ces domaines.
« On trouve plus facilement à sous-traiter des compétences dans le domaine des bases de données relationnelles que dans d’autres technologies émergentes ».
Assurez-vous également de prendre en compte la disponibilité du personnel qualifié dans la sélection de votre SGBD. Évaluez la disponibilité et les compétences des administrateurs de base de données et des développeurs d’applications ; prenez en compte les années d’expérience et les certifications techniques. On trouve plus facilement à sous-traiter des compétences dans le domaine des bases de données relationnelles que dans d’autres technologies émergentes.
Pour mesurer l’efficacité potentielle d’un SGBD par rapport à vos besoins, l’un des éléments les plus importants est probablement l’évaluation comparative des performances. Toutefois, le recueil d’informations pertinentes sur les performances est loin d’être facile.
Certes, vous trouverez des évaluations comparatives standard auprès du Transaction Processing Performance Council. Mais un tel banc d’essai est rapidement dépassé : il constitue rarement un indicateur fiable des performances réelles d’une mise en œuvre chez le client final.
« Certains fournisseurs, comme Oracle, interdisent aux clients de publier des informations sur les performances de leurs SGBD ».
De plus, les conditions contractuelles de certains fournisseurs, notamment Oracle, interdisent aux clients de publier des informations sur les performances de leurs applications de base de données. La meilleure méthode à votre disposition est donc d’étudier les bancs d’essai publiés et de demander aux éditeurs de vous indiquer des clients de référence.
Une autre possibilité consiste à installer un SGBDR d’essai et à développer des applications factices afin d’évaluer les performances du SGBD avec vos données, mais l’approche est chronophage.
L’investissement dans un SGBD est à long terme : son évolutivité pour accompagner la croissance des données, des utilisateurs et des processus est donc un facteur important. La prise en charge de cette croissance passe généralement par la capacité à répartir les données sur les différents noeuds d’un système distribué. Cette évolutivité a d’autres répercussions : vous devez notamment comprendre comment le produit s’adapte aux mises à niveau matérielles et connaître les limites de son architecture. Certes, les produits SGBDR offrent de bonnes capacités d’évolution. Toutefois, pour les volumes très importants de données, d’autres solutions SGBD pourront mieux convenir.
Veillez à vérifier la tolérance aux pannes de chaque SGBD. Un SGBD doit pouvoir supporter des erreurs de logique et de codage sans s’écrouler.
De plus, un système de gestion de base de données s’appuie sur divers composants pour assurer ses services de traitement des données. Un SGBD tolérant aux pannes doit donc continuer à fonctionner, même à un niveau réduit, plutôt que de s’arrêter complètement en cas de panne d’un de ses composants ou d’un composant qu’il utilise.
Enfin, il convient d'étudier les mécanismes de sécurité intégrés à la base de données. Outre la protection du réseau, passez en revue les fonctionnalités en place pour administrer les accès des machines et des humains au SGBD. Les connecteurs sont-ils suffisamment robustes ? Existent-ils des moyens pour restreindre les activités par rôle ? Les pistes d’audits sont-elles suffisamment précises pour remonter jusqu’à la cause profonde en cas de problème de sécurité ? Ensuite, considérez les méthodes de chiffrement de données au transit et au repos implémentés à même le SGBD. Au cours des cinq dernières années, la plupart des éditeurs et les responsables des projets open source ont renforcé ce point. De moins en moins optionnelles, les capacités de masquage de données personnelles ou sensibles par colonne, par ligne, voire par cellule peuvent également être un critère de choix.
