--- Begin Message ---
|
Subject: |
Re: [Phpcompta-contrib] MySQL au lieu de PostgreSQL |
|
Date: |
Tue, 25 Jan 2005 13:46:45 +0100 |
|
User-agent: |
Mozilla Thunderbird 0.7.1 (X11/20040626) |
En fait je pensais extraire le code sql pour le mettre dans un "fichier"
(ou groupe de fichier) à part (tout au même endroit).
Pour "faire" une version à chaque base de donnée en très peu de temps
(réécrire les requettes - c'est tout) et passser d'une version à l'autre
avec juste (par exemple) une variable gloable style DEFINE
PATH_SQL="/cgi/mysql/" ou PATH_SQL="/cgi/pgsl/"
et dans les fichier php :
include(PATH_SQL."fichierinclus.php);
Il suffit "juste" de "normaliser" les fichiers qui intéragissent avec
les base de données pour pouvoir faire une version pour chaque base de
donnée.
Le modèle de pear est :
requete [encpasultation du sql dans requette pear] -> pear (qui gère des
formats différents] // réécriture des requetes suivant la base (comment
gérer les champs autoincrément par exemple ? //-> interrogation base de
donnée -> récupération des résultats -> retour.
Le modèle qui m'attirait est :
fonction php -> mysql -> requete mysql
ou -> pgsql -> requete pgsql
par exemple insère_écriture ("libelle","montant","d/c") -> Numero écriture.
Le contenu de la fonction sera différente entre mysql et pgsql mais
renverra la même info. la logique interne de la base de donnée sera
occulté par la requette. et ce n'est pas "très" compliqué. Oui cela
implique un peu plus de travail (car il y a plusieurs branches) mais
comme les branches sont bien distinctes (pas la même base de donnée),
les 2 versions n'ont pas à être au même niveau à l'heure exacte. lorsque
il y a une release baseA ou baseB ou baseC : on prend les fichiers
php_comptacore + fichiers BD sur le cvs, les fichiers de la base sur
laquelle tu ne travailles pas ne changement rien pour toi, même si ils
ont 5 ou 6 jours de retard su la version live.
OK toutes les bases devront "attendrent" les mise à jours de Dany et de
"l'équipe en chef" qui maintiend le CORE phpcompta sur pgsql avant de
pouvoir répercuter sur les autres bases (par exemple lors de l'ajout de
nouvelles fonctionnalités). cela ne me dérange pas.
Oui, cela demande plus "d'ingénierie" (séparer le sql du code), c'est
l'habitude que j'ai, comme beaucoup, je pense.
Stan Pinte wrote:
Yannick Warnier wrote:
Le mardi 25 janvier 2005 à 10:16 +0100, herve couvelard a écrit :
Penses tu sérieusement que des personnes vont utiliser phpcompta dans
un environnement Oracle ? (autre que en local pour tester ?) tu as
une license oracle (autre que home ?)
Combien d'utilisateur php + sybase ?
Pour l'instant, et à ma connaissance, phpCompta est le seul outil libre
de compta qui permette de tenir une comptabilité belge (quoique j'ai
entendu parler de Dolibarr mais je n'ai jamais été voir plus loin).
Il en existe un autre: sqlledger. Il est à mon avis plus usine à gaz, et
développé en perl. Mais il offre du support payant...ce qui est pas mal.
À ce
titre, n'importe quelle entreprise pourrait vouloir l'utiliser et
l'intégrer à son système de bases de données. C'est un fait.
oui. lance-toi dans le dev oracle si tu veux.
Très sincèrement tu me déçois en affirmant (je paraphrase) que tout
réécrire à chaque nouveau système de bases de données est mieux que de
devoir installer PEAR.
quand il parle de tout réécrire, je suppose qu'il s'agit de réécrire le
ficher texte qui contient les requêtes SQL, non?
--> ou y-a-t'il d'autres choses?
------------------------------------------------------------------------
_______________________________________________
Phpcompta-contrib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/phpcompta-contrib
--- End Message ---
signature.asc