Bonjour,
 
Dans le cadre d'un projet personnel, plusieurs amis et moi avons décidé de ne pas limiter notre appli à un seul type de sgbd mais d'essayer de faire un truc un peu plus souple ... En gardant une certaine couche d'abstraction ... Voila ce que nous avons pensez :
 
une interface SQL implemente une classe (abraite ou non, ça dependra des differences entre les differents sgbd) SQLquery qui etend toutes les classes filles (mysql, postgres, oracle,...).  
 
SQL defini toutes les methodes qui seront indispensables au bon fonctionnement de l'appli, SQLquery pose les fonction "de base" (celles qui sont pareilles pour tous les types de base de donner) et apres en cas de trop grosse modification, la classe fille surcharge les methodes necessaires...
 
Mon probleme est le suivant : Pour commencer je teste avec postgres et mysql , qui sont les 2 sgbd que j'ai a disposition actuellement, et auquels est destinés actuellement notre appli (c'est qqch de petit, pas assez grande pour justifier Oracle ... Et pas de SQL Server pour le moment vu que je developpe sous linux), et deja a la creation de base de donnée je me trouve avec 2 choses assez differentes ... Pensez vous que ma structure soit possible ou les differences entre les differentes bases sont telles que je vais de toutes façon avoir la grande majorité du code dans les classes filles? Ou a la limite existe-t-il une norme (Je sais que celle SQL92 n'est pas suivie ...) meme si restrictive (vu la taille de l'appli, seules les fonctions tres basiques seront necessaires ... ) respectée par les sgdb "usuels" ?  
 
 
Merci d'avance

Bonjour,
Je viens d'en parler a des collegues du bureau et ils m'ont confirmer que les differences entre les differents types de base ne vont pas me simplifier la vie ... Il faudra que je definisse une sorte de patern pour mes requetes, qui sera completer par tous les types de base ... Parcontre, conaissez vous une sorte de dictionnaire qui recenserait les differences dans les requetes les plus courrantes et ceci entre les principales bases de donées ?  
 
Merci d'avance

Déjà, ton appli, elle tourne sous quelle plateforme, quel langage. T'as déjà des tas de librairies côté langage ou système qui font cette abstraction (MDAC sous Windows par exemple)
 
Ensuite, dans tes class, tu va devoir utiliser des séries de constantes/tableaux afin de faire correspondre les types de ton langage avec ceux des SGBD.
 
Récupère un AMC Designer (très vieil outils de modélisation de bases de données) : il était multi-base, et se basait sur des fichiers listant tous les éléments nécessaires pour générer le code SQL correspondant.
 
Par exemple :
 
Pour MySQL :

 
Pour SQL Server :

 
Evidement, cette liste n'est pas exhaustive. En te basant sur ces fichiers, tu devrais avoir une liste exaushtive de tous les éléments à prendre en compte pour rendre les requêtes compatibles d'un SGBD à l'autre.
 
Ensuite, pour les types, ben comme j'ai dit : dans ton appli, tu ne réfléchis qu'en fonction des types du langage utilisé. Ensuite, un simple tableau de correspondance te permet de retrouver le type correspondant à celui de ton programme.
Evidement, pour certains types, c'est pas aussi simple que ça.

Ah au fait, un point important...
 
Plutôt que coder ta propre couche d'abstraction pour ce qui est la connection aux bases, réutilise quelquechose d'existant, basé sur des drivers. ODBC est une très bonne solution, car multi-plateforme. (et ne me dit pas qu'il n'y a pas d'ODBC sour Linux, c'est faux )
 
En effet, si tu passes par une cnx ODBC, il y a plusieurs GROS avantages :
- A chaque mise à jour des versions de SGBD / drivers ODBC, l'appli peut en tirer parti sans devoir être modifiée/recompilée
- Dès qu'un produit propose un nouveau pilote ODBC, il peut être plugé à l'application sans problème
- En te basant sur des fichiers comme le faisait AMC Designer pour les éléments particuliers des SGBD, tu peux ainsi rester compatible avec des produits très exotiques et ce, sans jamais devoir recompiler l'application (ce qui me semble être le plus important dans la vie d'une application : les gens qui voudrons s'en servir dans 10 ans, quand tu sera PDG de esox_international, ils n'auront plus de support pour faire rendre compatible l'appli avec leur SGBD : il est donc important de ne pas être lié au code pour la compatibilité.

Donc Je tourne effectivement sous linux pour le developpement ... Mais ça doit tourner aussi sous Windows etant donné que certains des mes amis sont windowsiens ..
Le langage ou plutot les langages : PHP et Java (possibilité de quelques plugins Cgi C++ dans un futur pas trop lointain).
 
Du coté de PHP, pear propose une couche d'abstraction ... Mais je me rapelle que quand je l'avais utilisée il y a quelques années, je l'avais trouvée inconfortable au possible et assez mal ecrite ... Donc je prefererais eviter de me baser la dessus...
 
Pour ce qui en est des drivers ODBC, notre appli devrait tourner en mutualiser (Peu proposent Java malheureusement, on va devoir chercher ), est-ce que tu sais si c'est chose courrante de les utiliser sur ce genre de serveur?
 
Merci beaucoup
 
Esox

pour info : http://fadace.developpez.com/sgbdcmp/fonctions/

Salut orafrance ..  
Merci pour ton lien, ça me sera bien  utile Faut juste que je trouve qqch de pareil pour mysql / postgres

 
Ca dépend de l'hebergeur.
Oracle est systématiquement livré avec la couche ODBC pour Unix, et depuis un serveur Oracle sous Unix, on peut aisément appeler une base SQL Server sour Windows via un pont ODBC.
 
A partir de là, en généralisant un peu, je pense que la plupart des SGBD pour X-like offrent un support ODBC aussi bien serveur que client.
 
Ensuite, si les serveurs mutulalisés l'installent... c'est une autre histoire
En tout cas, c'est un standard qu'on trouve très souvent en monde hétérogène y compris sous Unix.

l'article est une bonne base, mais n'a pas l'air super actualisé.
 
par exemple, sous SQL Server, (donc MS dans l'article), il y a bien la fonction variance, alors qu'elle n'est pas indiquée dans l'article :
 

Tiens j'ai fais le même truc cette année avec un pote, mais on a couplé ca avec un webservice....et tu pouvais même générer un rapport en PDF.
En fait tu filais un fichier XML de configuration et roule ma poule....bon on en a chié mais ca marchait bien.

Ou j'ai pas bien saisi le problème, ou tu veux un peu réinventer la roue. Ou les roues existantes ne te paraissent pas suffisantes.
 
C'est un truc genre Java -> Spring que tu cherches ?!
 
Je ne pense pas que tu puisses entièrement abstraire toutes les requêtes, même en fabricant un langage "évolué".
 
Et ODBC ?