Quelle base relationnelle choisir ? Atouts et faiblesses des SGBDR

Atouts des SGBDR

Lorsque l’on achète un SGBD, il est fortement conseillé d’évaluer d’abord les candidats SGBDR car ils s’appliquent à de nombreux cas pratiques.

Grâce à leur base théorique solide, ils protègent et garantissent un accès continu aux données dans de nombreux types d’applications. C’est Ted Codd qui a élaboré ce modèle relationnel dans les années 1970 chez IBM. Fondé sur la théorie mathématique des ensembles, il apporte rigueur et précision à l’accès et à la manipulation des données.

La plupart des types de middleware, de produits logiciels d’intégration et d’outils de gestion sont disponibles pour les SGBDR, à l’inverse d’autres formes émergentes de SGBD.

De plus, vous trouverez facilement des programmeurs SQL pour contribuer au développement des SGBDR. Même si ce n’est pas une obligation, la plupart des SGBDR utilisent SQL comme langage standard d’accès aux données. Malgré des différences d’implémentation du langage SQL d’un SGBD à l’autre, la plupart des caractéristiques sont les mêmes quelle que soit la base de données relationnelle.

La fonctionnalité la plus intéressante des SGBDR est sans doute la robustesse de leur implémentation des propriétés ACID (atomicité, cohérence, isolation et durabilité) des transactions. Ce sont ces propriétés qui garantissent un traitement fiable des transactions de base de données. Ainsi, une transaction exécutée dans une base de données relationnelle est soit complète et produit des résultats corrects et à jour, soit un échec et ne produit aucun effet. Dans les deux cas, la base de données restera cohérente.

La prise en charge ACID consomme du temps de traitement. La disponibilité des données peut s’en trouver réduite, car les transactions suivantes doivent attendre la validation des données modifiées dans la base de données.

C’est une contrepartie justifiée lorsqu’il s’agit de données stratégiques comme les transactions financières. Les données bancaires doivent toujours être exactes et à jour. C’est aussi le cas d’autres types de données critiques de production, par exemple dans les secteurs de la santé, de la bourse, de l’assurance et d’autres secteurs réglementés.

Soyons justes : même si la cohérence stricte est la règle dans les produits SGBDR, la plupart laissent les gestionnaires de bases de données contrôler la cohérence à l’aide de paramètres ou de code jouant sur les niveaux d’isolation et de verrouillage.

Faiblesses éventuelles des SGBDR

La présence croissante d’applications qui exigent des types et des volumes différents de données complique la prise en charge de tels besoins par un SGBDR.

Les données des médias sociaux, les flux audio et vidéo en continu et l’Internet des objets (IoT) englobent des contenus différents qui exigent davantage de souplesse que les SGBDR classiques n’en offrent normalement.

Il y a bien évidemment d’autres points à surveiller avant de décider de l’acquisition d’un SGBDR. Le prix élevé en est un, c’est même un des principaux obstacles à cette acquisition. Le prix d’achat d’un SGBDR varie de plusieurs milliers de dollars à plus d’un million selon le volume des données ou la taille de la machine sur laquelle vous exécuterez la base. Le modèle économique à la demande (DbaaS) dans le cloud réduit la barrière à l'entrée et est synonyme d'une gestion simplifiée, mais le contrôle des coûts d'exécution devient alors primordial. 

La débauche de fonctionnalités des offres de bases de données relationnelles est un autre problème.

Si leur longévité rime avec fonctionnalités robustes et éprouvées par le temps, les SGBDR contiennent parfois des fonctions inutiles. Les logiciels affligés de boursouflure fonctionnelle sont difficiles à appréhender et à prendre en charge.

En outre, ces fonctionnalités supplémentaires peuvent paralyser les performances des bases de données, ce qui n’est pas le cas d’un SGBD sans fioritures, conçu et optimisé pour un seul scénario.

Les nouvelles combinaisons matérielles favorisant la séparation du stockage et du calcul tendent à lisser ce problème, mais encore faut-il que la version de la base de données choisie s'adapte à cette modernisation des infrastructures.

Un dernier inconvénient, qui peut être un atout selon le cas d’utilisation, est la rigidité du schéma qu’exigent les bases de données relationnelles.

Avant de pouvoir utiliser une table d’une base de données relationnelle, il faut prédéfinir toutes les colonnes avec un type et une longueur de données précis.

On améliore ainsi l’intégrité des données ; en effet, seules les données dont le type et la longueur sont corrects pourront être stockées dans la base.

Les systèmes plus récents de base de données NoSQL n’ont pas cette limitation : les développeurs peuvent adapter les schémas en fonction de l’évolution des besoins, même si cela comporte le risque de créer des problèmes d’intégrité.