Discussion :

[hisoft]

Bonsoir,

Je suis en cours d'étude d'une architecture pour une application J2EE. Au niveau de la couche de bonnées, je désire que l'appli soit indépendante du SGBD cible. En gros, que le SGBD soit Mysql, MSSQL, Oracle, DB2, ou autre mes requêtes devraient fonctionner à tous les coups. D'où la question : Quelle(s) technique(s) pour l'écriture de requêtes SQL en fonction du SGBD ?

Faut-il faire une requête pour chaque SGBD à prendre en compte et ensuite sélectionner la bonne en fonction du paramétrage de l'appli ?

Toute idée est la bienvenue.

Merci.

[al1_24]

C'est ça ou n'utiliser QUE les instructions et fonctions communes à TOUS les SGBD que tu dois pouvoir adresser.
Dans les outils de reporting, par exemple, il est courant d'utiliser un glossaire des fonctions propres à chaque SGBD et de préparer la requête en fonction des particularités de chacun.

[SQLpro]

non, AL24, c'est absolument pas le bonne technique. Je suis en train d'écrire un article qui montre que même un simple SELECT sans clause WHERE et sans transformation, ne peut s'écrire de la même manière sur touts les SGBDR.

le seul moyen est de ne faire que des procédures stockées et de masquer la complexité des requêtes de chaque SGBDR dedans.

A +

[Jester]

Il faut faire un DAO qui fait abstraction du stockage effectif des données. Ensuite vous pouvez commencer à faire un DAO SQL quasi normatif (i.e. qui marchera un peu sur tous les SGBD que vous considérez) et ensuite un ou plusieurs DAO spécifiques utilisant des optimisations, possiblement, faire un DAO qui utilise des procédures stockées (qui serait aussi donc presque indépendant du SGBD).

Par contre pour de la dev utiliser un DAO qui ne fait que du SQL simple permet de mieux identifier les problèmes et d'aller plus vite je trouve. Mais ça dépend de votre contexte.

[hisoft]

Merci pour vos réactions.

Les procédures stockées me semblent une bonne idée. Mais y aurait-il un ou des inconvénients ? Par exemple, est-ce une bonne démarche, du point de vue développement, je ramener tous les traitements côtés SGBD ? En plus, que faut-il alors faire avec les SGBD ne supportant pas les procédures stockées ?

Merci.

[SQLpro]

Merci pour vos réactions.

Les procédures stockées me semblent une bonne idée. Mais y aurait-il un ou des inconvénients ? Par exemple, est-ce une bonne démarche, du point de vue développement, je ramener tous les traitements côtés SGBD ? En plus, que faut-il alors faire avec les SGBD ne supportant pas les procédures stockées ?

Merci.

Est-ce une bonne démarche ?

de plus les SGBDR sont bien plus pérenne que n'importe quel code... Java devait être enfin le langage universel... Que dire alors de tous ceux venus après : Php, perl, python, C#...

Pour les SGBDR ne supportant pas les proc stock : ils sont condamnés a mort et ne peuvent supporter de charge. Par exemple Access ! Donc inutile de songer à un quelconque investissement pérenne de ce côté !

A +

[hisoft]

J'ai visité les liens et je vois que tu es défenseur des SGBDR. J'espère que ce n'est pas pour ça uniquement que tu me conseilles les procédures stockées . Sinon, je ne suis pas assez armé pour faire part de la discussion mais je trouve quand même que certains SGBDR s'inspirent de nouvelles fonctionnalités et spécifications (amélioration/gestion des pools de connexion, des transations, etc ...) issues du monde des frameworks pour palier certaines lacunes ou insuffisances. Pour moi, ils s'auto-complètent !

J'espère par ailleurs lire la réaction d'un spécialiste Objet, qui lui aussi pourrait étaler ses points de vue.

Je suis tout de même d'accord avec toi lorsque tu dis que les développeurs ne profitent pas pleinement des capacités des SGBDR les poussant souvent à se casser la tête côté métier, va savoir pourquoi ...

A+

[Maximil ian]

Autre piste : beaucoup d'outils de mapping objet-relationnel sont multi-SGBD. Ils gèrent de manière transparente un certain nombre de spécificités des bases avec lesquelles ils dialoguent.

Si l'ORM est une option pour toi, ça peut te simplifier la vie.

[hisoft]

Autre piste : beaucoup d'outils de mapping objet-relationnel sont multi-SGBD. Ils gèrent de manière transparente un certain nombre de spécificités des bases avec lesquelles ils dialoguent.

Si l'ORM est une option pour toi, ça peut te simplifier la vie.

Mon soucis principal se situe au niveau de la compatibilité des requêtes : si ce n'est que savoir si c'est un if (...,...,...) qu'il faut ou un CASE ... WHEN ... THEN ..., ou des trucs simples du genre, ça pourrait se gérer mais quand je pense aux fonctions (de dates, de chaines de caractères, de nombres, etc ...) qui existent ça et là et implémentées de diverses façons d'un SGBD à l'autre, je me demande quel(s) ORM gére(ent) cela ?

A+

[Maximil ian]

Mon soucis principal se situe au niveau de la compatibilité des requêtes : si ce n'est que savoir si c'est un if (...,...,...) qu'il faut ou un CASE ... WHEN ... THEN ..., ou des trucs simples du genre, ça pourrait se gérer mais quand je pense aux fonctions (de dates, de chaines de caractères, de nombres, etc ...) qui existent ça et là et implémentées de diverses façons d'un SGBD à l'autre, je me demande quel(s) ORM gére(ent) cela ?

Au contraire, je pense que les fonctions de dates et chaines de caractères sont mieux supportées que des choses comme les branchements conditionnels

Un exemple avec Hibernate et HQL :

http://docs.jboss.org/hibernate/core...ql-expressions

Après c'est sûr que les expressions les plus complexes (requêtes récursives, fonctions OLAP...) ont peu de chances d'être gérées en agnostique.

[SQLpro]

J'ai visité les liens et je vois que tu es défenseur des SGBDR. J'espère que ce n'est pas pour ça uniquement que tu me conseilles les procédures stockées . Sinon, je ne suis pas assez armé pour faire part de la discussion mais je trouve quand même que certains SGBDR s'inspirent de nouvelles fonctionnalités et spécifications (amélioration/gestion des pools de connexion, des transations, etc ...) issues du monde des frameworks pour palier certaines lacunes ou insuffisances. Pour moi, ils s'auto-complètent !

Sauf que c'est exactement l'inverse. Les SGBDR existent maintenant depuis 30 ans, et ce sont les framework et les ORM ainsi que les serveurs objet (arrivé dans les années 90/2000) qui se sont inspirés de ce que font les SGBDR pour faire leur sauce en moins bien et moins performant.
L'exemple typique est hibernate que les jeune développeur considèrent comme le graal absolu alors qu'ils n'ont absolument aucune culture SGBDR et qui provoque les pires maux comme je l'ai montré dans mes papiers.
les problème provoqué par les ORM sont récurrents et conduisent à des performances catastrophiques !

A +

[hisoft]

Au contraire, je pense que les fonctions de dates et chaines de caractères sont mieux supportées que des choses comme les branchements conditionnels

Un exemple avec Hibernate et HQL :

http://docs.jboss.org/hibernate/core...ql-expressions

Après c'est sûr que les expressions les plus complexes (requêtes récursives, fonctions OLAP...) ont peu de chances d'être gérées en agnostique.

Je pense que tu m'as mal compris ! Je ne dis pas que les ORM ne gérent pas de fonctions de traitement (nombres, chaines, date, etc ...) mais plutôt que ces fonctions sont limitées !
Autrement dit, est-il sûr de pouvoir toujours trouver (dans le cadre des fonctions par exemple) l'équivalent de telle ou telle fonction d'un SGBDR au sein de Hibernate ? J'imagine que non !

A+

[CinePhil]

Je suis en cours d'étude d'une architecture pour une application J2EE. Au niveau de la couche de bonnées, je désire que l'appli soit indépendante du SGBD cible.

Pourquoi ce désir d'universalité ?

Si ton appli peut avoir une importance stratégique ou critique pour les entreprises qui l'adoperont, celles-ci voudront sans doute qu'elle s'appuie sur un SGBDR robuste et ne feront pas la fine bouche si tu leur dis que ton appli ne fonctionne que sur un SGBDR payant tel Oracle ou MS SQL Server. Elles n'hésiteront pas non plus à investir dans un nouveau serveur pour héberger ton appli miracle qu'ils attendaient depuis longtemps et leur fera gagner des parts de marché ou de la productivité.

Si ton appli est moins importante (ne vois rien de péjoratif dans cete expression), fais-là tourner sur un SGBD gratuit ou deux (MySQL et/ou Postgresql, avec la restriction que MySQL n'est aps forcément gratuit) et cette "obligation" ne posera de problème à mon avis qu'à très peu d'entreprises ou d'organismes qui ont probablement déjà une appli php/mysql ou autre qui traîne dans un coin.

Si tu tiens absolument à l'universalité, comme il a été expliqué dans les précédents messages, c'est très difficile !
Utilise au maximum une syntaxe SQL normalisée. Mais le diable étant dans les détails, tu tomberas probablement sur des cas insolubles. Il sera alors temps de créer les fichiers de variables spécifiques aux différents SGBD que tu souhaites utiliser.

Bon courage !

[hisoft]

Pourquoi ce désir d'universalité ?

Si ton appli peut avoir une importance stratégique ou critique pour les entreprises qui l'adopteront, celles-ci voudront sans doute qu'elle s'appuie sur un SGBDR robuste et ne feront pas la fine bouche si tu leur dis que ton appli ne fonctionne que sur un SGBDR payant tel Oracle ou MS SQL Server. Elles n'hésiteront pas non plus à investir dans un nouveau serveur pour héberger ton appli miracle qu'ils attendaient depuis longtemps et leur fera gagner des parts de marché ou de la productivité.

Si ton appli est moins importante (ne vois rien de péjoratif dans cete expression), fais-là tourner sur un SGBD gratuit ou deux (MySQL et/ou Postgresql, avec la restriction que MySQL n'est aps forcément gratuit) et cette "obligation" ne posera de problème à mon avis qu'à très peu d'entreprises ou d'organismes qui ont probablement déjà une appli php/mysql ou autre qui traîne dans un coin.

En effet, l'application est destinée à des clients potentiellement importants. En plus, un des pré-requis de l'appli est qu'il n'y ait pas d'handicap par rapport aux SGBDR. Il n'est pas du tout question de rester à négocier avec un client le type de SGBDR à utiliser ou d'être limité dans son offre. Puisque certains peuvent être partenaires de telle ou telle firme (Oracle, Microsoft, etc ...) et par conséquent seront le plus souvent contraints de passer par le SGBDR de leur partenaire (performants ou pas) !
Je pense que là tu percois mieux la nécessité d'indépendance vis à vis des SGBDR.

Si tu tiens absolument à l'universalité, comme il a été expliqué dans les précédents messages, c'est très difficile !
Utilise au maximum une syntaxe SQL normalisée. Mais le diable étant dans les détails, tu tomberas probablement sur des cas insolubles. Il sera alors temps de créer les fichiers de variables spécifiques aux différents SGBD que tu souhaites utiliser.

Oui, j'y tiens. Au fait, je ne l'ai pas précisé mais l'application est en réalité déjà implémentée en J2EE et en production. Maintenant, certaines nouvelles spéc. (entre autres) veulent qu'elle soit ouverte aux autres SGBDR !
Sinon, j'ai trouvé une technique de gestion proposée par sun ici qui emploie les DAO (qui fait d'ailleurs partie de ma nouvelle architecture) !

Au plaisir !