Discussion :

[[ZiP]]

Bonjour,

J'envisage de développer une application web qui pourra supporter plusieurs types de base de données.

J'imagine que les requêtes peuvent avoir une forme différente en fonction du type de base de données utilisées.

On voit assez souvent MySQL et PostgreSQL.

A moins que la syntaxe des requêtes soit la même ?

Merci,
ZiP

[Celira]

En gros, il y a deux catégories de requêtes SQL :celles qui n'utilisent que le SQL Standard supporté par tout le monde et celles qui utilisent les fonctions natives.

Si tu n'utilise QUE des choses standard et quelque chose comme PDO pour exécuter tes requêtes, c'est transparent (sauf configuration du driver et de la connexion à la base)

Problème : personnellement, je n'ai jamais réussi à faire une appli qui utilise uniquement des fonctions standard

[[ZiP]]

Bonjour,

Merci pour votre réponse.

Je vais continuer de chercher pour trouver la solution la plus appropriée.

ZiP

[armel18]

Il y a des types de jointures conformes SQL2 qui sont supportées par PostgreSql et qui ne le sont pas avec mysql.Par exemple FULL JOIN est supportée par postgreSql.

Cependant au lieu d'écrire 2 fois la même requête, tu as tout à gagner à utiliser un orm qui fera abstraction du moteur de la BD sous-jacente. Ainsi tu n'auras ni à écrire 2 requêtes ni à t’intéresser des spécificités de mysql ou de postegresql.

[[ZiP]]

Quel outil ORM pour PHP me conseillez-vous ?

Merci,
ZiP

[gototog]

il y'a propel, doctrine et doctrine2; Vu que je traine autours des technos symfony, les autres je connais pas

[papajoker]

bonjour @zip
tu n'es pas précis dans ta demande, et du coup je trouve les réponses précédentes incomplètes

1) on ne change pas en cours de route de bases de donnée
2) on recherche une compatibilité db pour des "bundles"(packages) réutilisables entre projets

A) on doit utiliser au minimum PDO, pour être compatible au niveau php
B) la compatibilité sql est de 90% ?
Si tu dois changer de db pour tout ton projet, modifier "légèrement" 10..15 requêtes n'est pas trop encombrant.

C) non , l'orm n'est pas la solution miracle
l'orm ne peut générer des requetes trop complexes, donc si tu as des
requetes simples => elles sont déjà compatibles (95%?)
requetes "complexes" => l'orm ne servira à rien !

Donc, pour moi :
si tu écris un module actu,commentaires,acl : l'utilisation de l'orm est bonne
si tu développes un projet de gestion de stock, l'orm va atteindre ses limites

tu ne nous parles pas des triggers, de procédures stockées, ici l'incompatibilité est très très forte!

note: petits tableau pour la compatibilités des fonctions : http://sqlpro.developpez.com/cours/s...onctions/#L1.2

[ABCIWEB]

J'envisage de développer une application web qui pourra supporter plusieurs types de base de données.

Sur le papier évidemment c'est l'idéal.

En pratique ce n'est pas si simple notamment en termes d'optimisation. Un rowcount() qui peut éviter une requête n'est pas supporté par tous les sgbdd, ni un ON DUPLICATE KEY UPDATE qui permet selon les cas des gains de performances très significatifs.

Par ailleurs, passer par un ORM rajoute une couche de difficultés quant a l'optimisation finale. Tout n'est pas rose et c'est bien résumé dans ce topic

Donc oui l'idée est séduisante, mais avec les inconvénients et lourdeurs que cela impose, je ne le ferais pour ma part qu'en cas de nécessité absolue.

[[ZiP]]

Bonjour,

Je vais donc plutôt me limiter à un seul type de base de données : MySQL.

Merci pour vos conseils,
ZiP