Analyse et développement d'un logiciel de gestion des donneurs de sang:cas du CNTS

II.3.3. Choix du SGBD

De nombreux SGBD sont disponibles sur le marché, partant des SGBD gratuits jusqu'aux SGBD destinés spécialement aux professionnels, comportant de plus nombreuses fonctionnalités, mais plus coûteux.

Je vais essayer de faire comme d'habitude une étude comparative d'une sélection de quelques SGBD et choisir un pour mon application. En guise de cause, on mentionne quelques facteurs subjectifs qui influent souvent sur le choix du SGBD :

Ø La politique sécuritaire

Ø Le budget à disposition

Ø Les compétences déjà acquises en terme de développement et d'administration et au besoin du prix de la formation

Ø Le système d'exploitation hébergeant

Ø Les architectures logicielles et matérielles

Ensuite viendront des points tels que :

Ø La richesse fonctionnelle du SGBDR

Ø Les ressources (disques, mémoire, CPU, Transactions par secondes, nombre de connexions simultanées)

Ø L'attente que vous avez vis-à-vis du support technique

Ø Les compétences déjà acquises en termes de développement et d'administration

Ø Le type d'accès aux données (OLTP, décisionnelle, reporting, mixte)

Faisons l'étude de quelques uns qui sont connus par un grand nombre du public :

· Oracle Database

Oracle n'est pas un SGBDR optimisé pour de petites bases de données. Sur de petits volumes de traitements (2 Go par exemple) et peu d'utilisateurs (une trentaine).

· Avantage 

· Procédures stockés en PL-SQL (langage propriétaire Oracle, orienté ADA) ou en JAVA, ce qui peut s'avérer utile pour les équipes de développement.

· Assistants performants via Oracle Manager Server, possibilité de gérer en interne des tâches et des alarmes

· Gestion centralisée de plusieurs instances

· Concept unique de retour arrière (Flashback)

· Pérennité de l'éditeur : avec plus de 40% de part de marché, ce n'est pas demain qu'Oracle disparaîtra

· Réglages fins : dans la mesure où l'on connait suffisamment le moteur, presque TOUT est paramétrable.

· Accès aux données système via des vues, bien plus aisément manipulable que des procédures stockées.

· Services Web

· Support XML

· Ordonnanceur intégré

· Inconvénients

· Prix exorbitant, tant au point de vue des licences que des composants matériels (RAM, CPU) à fournir pour de bonnes performances

· Fort demandeur de ressources, ce qui n'arrange rien au point précité, Oracle est bien plus gourmand en ressource mémoire que ses concurrents, ce qui implique un investissement matériel non négligeable. La connexion utilisateur nécessite par exemple près de 700 Ko/utilisateur, contre une petite centaine sur des serveurs MS-SQL ou Sybase ASE. Gourmand aussi en espace disques puisque la plupart des modules requièrent leur propre ORACLE_HOME de par le versionning de patches incontrôlés.

· Porosité entre les schémas = difficile de faire cohabiter de nombreuses applications sans devoir créer plusieurs instances. Il manque réellement la couche "base de données" au sens Db2/Microsoft/Sybase du terme.

· Méta modèle propriétaire, loin de la norme.

· Tables partitionnées, uniquement possible à l'aide de modules payants complémentaires. Parallélisme mal géré sur des tables non-partitionnées.

· Gestion des verrous mortels mal conçue (suppression d'une commande bloquante sans roll back)

· Pauvreté de l'optimiseur (ne distingue pas les pages en cache ou en disque, n'utilise pas d'index lors de tris généraux, statistiques régénérées par saccade...)

· Pas de prise directe sur les tables système (vues système)

· Une quantité de bugs proportionnels à la richesse fonctionnelle, surtout sur les dernières versions

· Gestion erratique des rôles et privilèges (pas possible de donner des droits sur des schémas particuliers sans passer par leurs objets, désactivation des rôles lors d'exécution de packages...)

· Nombreuses failles de sécurités liées à l'architecture elle-même

· Access

Access est aussi bien un outil grand public que professionnel, selon les besoins qu'on a. Il est assez performant en tant que SGBD allié à un outil de développement intégré qui en facilite l'utilisation. Access peut, en tant qu'outil de développement, être utilisé conjointement avec un véritable Serveur de base de données SQL pour bénéficier des avantages du Client/serveur, sous certaines conditions. Un néophyte peut facilement utiliser Access et se créer une base de données complète, grâce à de nombreux assistants pour l'aider à remarquer son intégration dans Office.

Le problème est qu'Access en tant que format de données n'est pas un SGBD client/serveur mais seulement un SGBD fichier. Le trafic qu'il génère sur le réseau en utilisation réseau multiposte peut fortement perturber ses performances. Les performances chutent rapidement lorsque plusieurs utilisateurs sont connectés ou si la base dépasse les 100000 lignes. Cependant, Access en tant qu'outil de développement peut être utilisé conjointement avec un véritable Serveur de base de données SQL pour bénéficier des avantages du Client/serveur.

MS-Access reste un bon choix si vous souhaitez avoir une base de donnée de petite taille et facilement gérable, ou que vous ne connaissez pas grand chose aux SGBD.

En se référant du domaine d'application du logiciel à développer et de l'étude comparative faite entre les deux SGBD cités ci-dessus on a choisi Access.^6(*)

* 6 ^_ http://www.memoireonline.com/02/09/2005/m_Conception-et-Developpement-dun-logiciel--de-gestion-commerciale7.html