Re: [Phpcompta-contrib] MySQL au lieu de PostgreSQL

[Dany De Bontridder]

On Wed, 26 Jan 2005 12:55:09 +0100
herve couvelard wrote:

> 
> 
> Dany De Bontridder wrote:
> > On Tue, 25 Jan 2005 13:46:45 +0100
> > herve couvelard wrote:
> J'aime pas trop l'objet : dans un environnement client serveur : cela
>ne 
> se justifie pas car tous les objets doivent être recrées à chaque
>"page" 
> (get ou post). je connais l'objet, mais ne c'est pas mon fort.

Disons que le gros avantage de l'objet est de faire plus simple et plus
réutilisable, (voir la class User, balance, widget) avec le procédurale
on finit par se mélanger les pinceaux, puisqu'au lieu d'utiliser des
objets on utilise des structures de données dans un tableau, pas
toujours évident.

> Je penche plus pour une API fonctionnelle. Mais c'est au choix de la 
> majorité. L'avantage de l'objet est de fournir une encapsulation des 
> données dans un soucis d'intégrité : en clair : tu donne les objects 
> majeurs par exemple : database.add_compte() et
>database.delete_compte() 
> et ton objet database verifie que le compte n'est pas utilisé AVANT de
> faire delete_compte().
Je n'ai rien contre le procédurale mais il est moins souple, l'object
sous Php est simplissisme. Bien sûr il y aura toujours des petites
fonctions (FormatString, isNumber...)

> Si il faudrait pouvoir faire travailler phpcompta avec global à OFF.
ça c'est fait mais uniquement dans la version CVS.

> le reste : les sessions je ne connais pas, je n'ai jamais utilisé les 
> sessions php et ai toujours fait les miennes.
Très facile :-)

> 
> Oui, il faut une double couche d'abstraction : celle qui fait la base
> de 
> donné et celle qui fait le métier.
> par exemple  pour les métier : des masques de saisies "pré-remplies",
> 607   facture telecom
> 44566 tva facture telecom
> 410   prelev factu telecom en attente
> 
> puis
> 410 reglement facture telecom
> 512 reglement facture telecom
> 
> ces masques de saisies viendrait en partie avec phpcompta, d'autres
>avec 
>   des marties métiers/par exemple avec la partie analytique
> 
> exemple que j'aurais besoin de faire pour moi (en cours de reflexion)
> 
> 710   insertion client                100
> 44566 tva sur insertion               19.6
> 605num        part commercial         30
> 44567 tva sur commercial       5,
> 512   remise cheque           119,6
> 410num        part commercial                 35
> 
> un truc dans ce genre là.
> 
> Donc on fait "templates" de saisies.
J'ai l'impression que c'est ce que fait déjà phpcompta mais uniquement
en mode utilisateur, non ?

> 
> De même j'aurais besoins de sortir des états mensuels de parts 
> commercials par commerciaux  et régions, donc il y aura des
"templates" 
> de visualisation qui seront probablement fait avec des fichiers xml.
> Comme cela ce sera parfaitement paramétrable.
> par exemple pour chaque sous_comtes 605 avec les rèlements en attentes

Oui c'est la partie formulaire, ( OOo + fichier ini )  je n'ai pas
encore commencé cette partie-là, je dois d'abord améliorer les fiches
avant.

> pour l'instant je n'ai pas encore codé (j'en suis à la partie amont : 
> définir les besoins de mon applis métier et je cloture mon bilan
>   2004) Ensuite, il faut que je fasse les tables sql et que j'avance 
> petit à petit. Je ne sais pas encore dans quel sens je vais faire mes 
> modifs.
> 
> La question est de savoir comment on va travailler. :
> 
> Ma première impression est ; il faut que je fasse les premières
tables.
> Donc je vais faire un script pour installer la base avec mysql. Mais
en 
> php (cela élimine pas mal de problèmes de l'installation avec les
> droits 
> et tout et tout) le user ayant créé la table ayant les bons droits.
D'accord, je compte faire un installeur qui permettent non seulement de
créer correctement les db mais aussi d'appliquer les patchs si la bdd
évolue et surtout de tester que l'environnement est ok. Mais ça aussi
c'est encore en projet. Ton idée est dans la bonne direction :-)

> Comment fait-on ?
> au fur et à mesure de mon avancé, il y aura des modifications parfois 
> majeures dans tes pages notamment pour extraire le code sql ou 
> transformer des fonctions par des includes par exemples (gain x10 en 
> rapidité et charge pross).
> Je ne suis pas compétent avec pgsql, donc je ne pourrais pas
>travailler 
> cette partie et je ne pourrais QUE faire le code mysql.
Du Sql c'est du sql mais je testerais sur psql pour toi, no problem

> tu travailles avec cvs ? je ne sais pas comment cela marche, mais je 
> pense trouver rapidement si besoin.
> 
> on travaille avec des diff ? (je sais pas non plus, mais je comprend 
> vite) l'avantage est de "voir" les changements.
Oui je préfère, au moins au début, il suffit de faire un cvs co
(voir sur savanah) pour avoir la dernière version puis quand tu as fini
tu fais 

cvs rdiff -c  >patch-herve-numero

Une fois que je l'ai intégré tu n'as plus qu'à faire cvs update pour
avoir ton répertoire de travail à jour. 

On verra si on peut travailler ainsi, je suis un peu frileux de donner
accès au CVS: récupérer les erreurs est _TRES_ pénible.

> 
> Le mieux est que je te contacte lorsque j'attaque "pour de vrai".
> 
> Au fait : il y avait pas quelqu'un qui travaillait sur le plan
>comptable 
> francais ?
Euh oui mais je ne l'entends plus, je lui ai envoyé le plan comptable
français puis... plus de nouvelles

@+,

D.