Bonsoir,
Que pensez-vous d\'utiliser une couche d\'abstraction de bases de données comme ADOdb pour permettre l\'utilisation d\'autres bases de données ?
Ce sera une modification profonde du code !
Si cette idée est retenue, il faut à mon avis faire un appel de fond pour payer un développeur qui le fera.
Merci de vos retours
Papilip
Utilisation d\'une couche d\'abstraction pour la DB
Re:Utilisation d\'une couche d\'abstraction pour la DB
Bonjour,
Ce serait pas mal, mais je vois immédiatement 5 de problèmes.
1. La gestion des transactions n\'est pas la même suivant les RDBMS, le système de patch automatique de la base de données en tire profit avec postgres qui permet d\'annuler des DDL, et donc si un patch échoue laisse la base de données dans un état cohérent, ce qui n\'est possible ni avec Oracle ni avec mySQL, pour ces RDBMS les transactions ne concernent que les DML. Il faut réécrire le code pour patcher les bases de données automatiquement ou sacrifier cette possibilité ou avoir une méthode par RDBMS, il n\'y a pas de méthode standard.
2. Les schémas sont utilisés comme namespace, sous Oracle ou mySQL par exemple ce ne serait pas possible, Oracle intéprète les schémas comme un espace pour un utilisateur et mySQL ne l\'implémente pas du tout. Tout le système de plugin fonctionne avec ce mécanisme, cela permet de clairement séparer ce qui fait parti du plugin et ce qui est dans phpcompta même, donc réécriture de tous les plugins. Postgresql suit les recommandations ANSI SQL à ce sujet.
3. On utilise beaucoup le PLPGSQL pour protéger la base de données de données, l\'objectif est d\'éviter qu\'une application ne puisse insérer des données incohérentes, cela concerne les balances, le plan comptable... Bref, pas mal de code a réécrire par RDBMS que l\'on souhaite supporter.
4. Création de modèle ou de dossier sur base de modèle, cette partie-là devra aussi être réécrite pour Oracle et mySQL, c\'est possible mais il n\'y a pas de méthode standard, il faudra une méthode par base de données
5. Le SQL de postgresql est standard, en fait, c\'est le RDBMS qui respecte le mieux les normes SQL. Malheureusement, les implémentations sont parfois différentes ou inexistantes : les clauses WITH...SELECT n\'existe même pas sous mySQL, pour Oracle à partir de la version 9 mais il n\'y pas encore toutes les possibilités. L\'auto-increment (serial pour postgresql) n\'existe pas sous Oracle même dans sa version 11. Beaucoup de query complexe devront être réécrite (y compris dans les plugins)
J\'imagine que le développeurs découvrira d\'autres problèmes
Bref, même avec une couche d\'abstraction, on devra recoder par base de données que l\'on veut supporter et donc multiplier les tests et scénarios pour tout vérifier pour chaque base de données. Uniqument ajouter mySQL sera déjà en soit un travail de titan sans compter que cela doublera les tests (qui sont déjà franchement longs ).
Ce serait pas mal, mais je vois immédiatement 5 de problèmes.
1. La gestion des transactions n\'est pas la même suivant les RDBMS, le système de patch automatique de la base de données en tire profit avec postgres qui permet d\'annuler des DDL, et donc si un patch échoue laisse la base de données dans un état cohérent, ce qui n\'est possible ni avec Oracle ni avec mySQL, pour ces RDBMS les transactions ne concernent que les DML. Il faut réécrire le code pour patcher les bases de données automatiquement ou sacrifier cette possibilité ou avoir une méthode par RDBMS, il n\'y a pas de méthode standard.
2. Les schémas sont utilisés comme namespace, sous Oracle ou mySQL par exemple ce ne serait pas possible, Oracle intéprète les schémas comme un espace pour un utilisateur et mySQL ne l\'implémente pas du tout. Tout le système de plugin fonctionne avec ce mécanisme, cela permet de clairement séparer ce qui fait parti du plugin et ce qui est dans phpcompta même, donc réécriture de tous les plugins. Postgresql suit les recommandations ANSI SQL à ce sujet.
3. On utilise beaucoup le PLPGSQL pour protéger la base de données de données, l\'objectif est d\'éviter qu\'une application ne puisse insérer des données incohérentes, cela concerne les balances, le plan comptable... Bref, pas mal de code a réécrire par RDBMS que l\'on souhaite supporter.
4. Création de modèle ou de dossier sur base de modèle, cette partie-là devra aussi être réécrite pour Oracle et mySQL, c\'est possible mais il n\'y a pas de méthode standard, il faudra une méthode par base de données
5. Le SQL de postgresql est standard, en fait, c\'est le RDBMS qui respecte le mieux les normes SQL. Malheureusement, les implémentations sont parfois différentes ou inexistantes : les clauses WITH...SELECT n\'existe même pas sous mySQL, pour Oracle à partir de la version 9 mais il n\'y pas encore toutes les possibilités. L\'auto-increment (serial pour postgresql) n\'existe pas sous Oracle même dans sa version 11. Beaucoup de query complexe devront être réécrite (y compris dans les plugins)
J\'imagine que le développeurs découvrira d\'autres problèmes
Bref, même avec une couche d\'abstraction, on devra recoder par base de données que l\'on veut supporter et donc multiplier les tests et scénarios pour tout vérifier pour chaque base de données. Uniqument ajouter mySQL sera déjà en soit un travail de titan sans compter que cela doublera les tests (qui sont déjà franchement longs ).
Re:Utilisation d\'une couche d\'abstraction pour la DB
En effet les objections évoquées laissent deviner la complexité du travail.
Je reste persuadé que c\'est possible, mais avec une prestation rémunéré à la clé.
Comme dit mon ami François Elie, le président de l\'Adullact : Un logiciel libre ne devient gratuit que lorsqu\'il a été payé !
Je reste persuadé que c\'est possible, mais avec une prestation rémunéré à la clé.
Comme dit mon ami François Elie, le président de l\'Adullact : Un logiciel libre ne devient gratuit que lorsqu\'il a été payé !
Re:Utilisation d\'une couche d\'abstraction pour la DB
Il n\'est toujours pas payé: 9 ans de travail, serveurs,... Cela ne se rembourse pas très vite 
Conclusion : PhpCompta est libre pas gratuit))
Conclusion : PhpCompta est libre pas gratuit
))