La question de la performance est vraiment mineure avec notre méthode actuelle d'abstraction à la base de données (c'est à dire de faire du SQL générique). En revanche, si on avait choisi une méthode d'abstraction plus "complète" du type "mapping objet relationnel", ça oui c'est trop coûteux en performances. En tout cas avec les tests réalisés il y a quelques années.
Piwigo disposait en 2.2, comme Perl avec DBI, d'une couche d'abstraction qui permet d'envoyer du SQL qui était ensuite exécuté soit par MySQL soit par PostgreSQL ou encore SQLite.
Le soucis principal, c'est que le SQL n'est pas vraiment générique. Certaines requêtes qui fonctionnent avec MySQL ne fonctionne pas avec PostgreSQL et inversement. Ca devient "compliqué". Or pour faire les choses correctement, il faudrait que tout le monde teste avec plusieurs bases de données : développeurs du "core" et développeurs de "plugins". Or ce n'est clairement pas le cas et c'est compliqué d'aller exiger des contributeurs qu'ils testent sur PostgreSQL dont ils se fichent un peu, pour ne pas dire complètement. L'important se situe davantage au niveau des fonctionnalités et de l'interface utilisateur plutôt que sur le moteur de base de données.
PostgreSQL est un excellent moteur de bases de données mais MySQL est également très bon et a l'énorme avantage d'être disponible absolument partout.
[^] # Re: Database
Posté par Pierrick Le Gall . En réponse à la dépêche Piwigo 2.3. Évalué à 6.
La question de la performance est vraiment mineure avec notre méthode actuelle d'abstraction à la base de données (c'est à dire de faire du SQL générique). En revanche, si on avait choisi une méthode d'abstraction plus "complète" du type "mapping objet relationnel", ça oui c'est trop coûteux en performances. En tout cas avec les tests réalisés il y a quelques années.
Piwigo disposait en 2.2, comme Perl avec DBI, d'une couche d'abstraction qui permet d'envoyer du SQL qui était ensuite exécuté soit par MySQL soit par PostgreSQL ou encore SQLite.
Le soucis principal, c'est que le SQL n'est pas vraiment générique. Certaines requêtes qui fonctionnent avec MySQL ne fonctionne pas avec PostgreSQL et inversement. Ca devient "compliqué". Or pour faire les choses correctement, il faudrait que tout le monde teste avec plusieurs bases de données : développeurs du "core" et développeurs de "plugins". Or ce n'est clairement pas le cas et c'est compliqué d'aller exiger des contributeurs qu'ils testent sur PostgreSQL dont ils se fichent un peu, pour ne pas dire complètement. L'important se situe davantage au niveau des fonctionnalités et de l'interface utilisateur plutôt que sur le moteur de base de données.
PostgreSQL est un excellent moteur de bases de données mais MySQL est également très bon et a l'énorme avantage d'être disponible absolument partout.