Développer une application – quel sgbd choisir.

Vous avez une superbe idée d’un logiciel  qui pourrait rapporter gros. Choisir le langage de programmation est toujours un défi mais en plus, l’application devra utiliser une base de données.

Maintenant, le SGBD (Système de gestion de bases de données) sur lequel devra reposer l’application reste à choisir. ORACLE, SQL SERVER, Sybase,  Mysql , PostgreSql, etc. Tous sont de bons SGBD mais lequel ciblera le plus grand nombre de clients.  Oracle un choix judicieux mais un peu complexe, SQL SERVER et Sybase également un choix averti, Mysql opensource et de plus en plus solide, PostgreSQL opensource solide avec des belles fonctionnalités.  Pourquoi ne pas en choisir plus d’un? En supportant, Oracle et SQL SERVER la majorité des entreprises ont déjà un ou l’autre de ces SGBD, ce qui vous permettra de bien démarrer.

J’entend déjà des commentaires;  comme c’est complexe à gérer. Il est certain que l’architecture de votre application sera un peu plus compleze mais combien polyvalente. Vous ne serez pas obligé de forcer vos clients à changer de SGBD et que ce dernier acquiert une expertise sur ce SGBD. Alors, comment faire ? Je vous propose donc une méthode, qui à mon sens est efficace et évolutive.

Normalement, les différentes requêtes d’accès aux données sont incorporées dans des procédures stockées sur le SGBD cible, ce qui permet une maintenance des requêtes aisée et sans être obligé de redéployer l’application.  La méthode proposée dans ce contexte, consiste à placer les requêtes dans un SGBD embarqué tel que Sqlite ou Mysql version embarquée. De cette manière, le nombre de requêtes par SGBD est facilement gérable.  Il ne reste qu’à alimenter cette base de données qui formera votre dictionnaire de requêtes.  Votre dictionnaire peut également contenir le texte de la création  des procédures stockées d’accès aux données lors de l’installation, selon le SGBD cible choisi par l’utilisateur.

Pour Sqlite un API de création de tables, d’ajout de données est disponible sous Microsoft Visual Studio. J’ai fais des test avec Sqlite et l’accès aux données est vraiment rapide et en plus toute la base de données est située dans un seul fichier de petite taille. Par contre, il ne supporte pas les procédures stockées, ce qui nous oblige à  se déclarer une classe qui gère l’accès au dictionnaire de requêtes mais on le fait qu’une fois.  D’autres produits existes également dans ce domaine comme SqlAnywhere ou Oracle Lite . Il ne vous reste plus qu’à faire le design de ce dictionnaire.

Pour le reste de votre application,  les accès aux données se feront de manière centralisés et sécurisés (en autant que vous avez pris le soin de sécuriser le tout).  Il est certain que cela peut être contraignant sur certains points mais je pense que cela peut aider dans un monde concurrentiel et en perpétuelle évolution. Une bonne analyse et un design de l’application est primordiale pour éviter les changements multiples oubliés. Il ne faut pas oublier également la sécurisation de la base de données embarquées et également sécuriser le code sensible.

Il serait également judicieux  d’écrire les requêtes selon la  norme  SQL92 (La majorité des SGBD l’ont implantée avec des variantes), ce qui permettrait de diminuer les différentes manières de contruire les requêtes. Seul les fonctionnalités propre au SGBD différeront, comme par exemple pour SQL SERVER avec la fonction de conversion de texte “convert” versus  Oracle avec “to_date” ou “to_number”.

Bon développement.