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

[Yannick Warnier]

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). À 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.
 
> >>la possibilité de le mettre sous acces ? oracle ? sybase ?
> 
> Ok : tu utilises quoi comme base de donnée (en production ?) ?
> php+access ? en production ? (je parle de access en production )

MySQL et PostgreSQL, là n'est pas la question.

> >>Quel impact en terme de client/utilisateur ?

Les clients ont-ils un rapport là-dedans?

> > Tu veux dire combien de personnes l'utiliseront vraiment? Tu peux voir
> > actuellement le nombre de personnes qui veulent l'utiliser sous MySQL.
> > PostgreSQL est pourtant libre et gratuit également. Pourquoi MySQL?
> 
> Quelle est la base de donnée la plus répandue avec php chez les 
> hébergeur ? d'après toi ?

MySQL, mais là n'est pas la question. Rare sont les sociétés (que je
connais) qui voudront consciemment héberger leurs données comptables
ailleurs que chez eux. C'est subjectif, tu peux probablement affirmer le
contraire.

> > 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.
> 
> pourquoi pas faire directement un logiciel de gestion d'entreprise qui 
> fasse pas en même temps les devis (ce ne sont que des lignes d'une base 
> de donnée), les factures (idem), les suivi clients (idem), les suivi 
> règlement, les gestion de rendez vous, puisque ce ne sont QUE des 
> extensions de la compta les clients -> des devis -> des factures -> des 
> écritures comptables . plutôt que de se faire C* à tout réécrire alors 
> qu'on a qu'a le faire avec phpcompta directement ?
> Ok c'est très caricatural.
> Tu as installé PEAR chez toi ?

Oui oui. apt-get install php4-pear

> Quel impact en terme de charge serveur ?

Je n'ai jamais ressenti le besoin d'éliminer PEAR, mais je sais que tu
fignoles beaucoup sur les micro-secondes, alors je t'accorde ce point
les yeux fermés. 

Ceci dit comme disait Dany, il y a d'autres alternatives également,
toutes multi-db. Si tu n'aimes pas PEAR, c'est ton choix.

> tu le trouves sur les serveurs hébergé mutualisé ?

Je n'utilise pas de serveurs hébergés mutualisés.

> tu suis les mises à jour de sécurité de PEAR  et autres application PEAR ?

Non, mais je te retourne la question par rapport à PHP, Apache et IIS
(ainsi, bien évidemment, que tous les modules d'Apache et que les
systèmes d'exploitations que ton hébergeur utilise). Enfin, c'est tout à
ton honneur si tu le fais...
Ceci dit, si je trouve une erreur dans PEAR, je n'hésiterai pas à la
rapporter à qui de droit. Je fais ainsi confiance à la communauté du
libre pour que les outils que j'utilise soient développés de la
meilleure façon.

> Il y a une différence entre réinventer la roue et utiliser la moindre 
> bibliothèque qui existe pour éviter_de_coder /gagner_du_temps / 
> de_la_pseudo_compatibilité.

...comme il y a une différence entre gagner du temps de développement
tout de suite à petite échelle et en gagner plus tard à grande échelle.

> Je devellope php + mysql depuis 98.

Hooooo :-)

> Oui pear apporterait porbablement pas mal de truc : dans ce cas pourquoi 
> ne pas faire un paquet PEAR:compta ? cela pourrait même apporter 
> vachement de chose bien à plein de monde (tous ceux qui utilise PEAR).
> Ils pourraient utiliser des objects compta (balance de comptes, 
> pointage, bilan) sur leurs applications web comme les forums : nombre de 
> messages, bilan des messages par sujets, catégorie. Nombre de messages 
> moyens par membres etc......

Tu t'emportes

> > Enfin, c'est mon avis et comme je le mentionnais en première ligne, je
> > ne ferai pas le boulot donc je suggère que celui qui le fait juge par
> > lui-même.
> 
> Utiliser des Classes extérieurs à beaucoup plus d'impact qu'on semble 
> vouloir le penser. Regarder le dev des logiciels 'libre' comme scribus, 
> inkscape, proftpd etc.....
> Regarder les problèmes qu'ils se posent avec les dépendances avec des 
> lib fait par des autres (on intègre ou pas ? )
> Tu installes inkscape sur ta machine, juste pour voir ? (pourtant 
> inkscape commence à pouvoir remplace illustrator dans un univers de dev web.

Tu t'emportes aussi. Si ça apporte des dépendances aux autres lib, ça
permet également de ne pas rencontrer les mêmes obstacles et ne pas
faire les mêmes erreurs. Cela m'émerveillerait si tu m'affirmais que
chaque fois que tu développes une librairie, tu vérifie l'historique de
développement de toutes les autres librairies comparables afin d'être
certain de ne pas laisser un trou de sécurité béant là où d'autres l'ont
déjà colmaté.

> Oui, il y a des moments ou on ne peut pas faire autrement
> gtk2 ? gtk+ ? librsvg ? libxml ? ok...
> Mais MON avis personnel (qui ne regarde que moi) est de ne JAMAIS 
> intégrer une lib/class pour "juste au cas ou."

J'ai bien compris. Tu préfères faire les erreurs toi-même. D'ailleurs
selon ton principe, il vaut toujours mieux tout redévelopper à la main.
Même tes librairies à toi, puisque le nouveau client pour lequel tu
développes n'a pas forcément besoin de "toutes" les fonctions de ta
lib...

> PEAR n'est pas aussi répandue que cela et l'installation de pear n'est 
> pas aussi trivial que cela. Sur MES serveurs de production, c'est 
> quelque chose que je n'ai pas envie de faire (j'ai probablement tort).

> OK dans l'absolue il faut réfléchir et ne pas réinventer la roue.
> Mais, pour ce cas particulier, cela apportera peu en terme de nouvelles 
> fonctionnalités :
> je connais peu de personnes que sont obligé de faire php+oracle 

Moi aucune, ce n'est pas une raison pour se mettre dans une position
instable pour l'avenir.

> et qui VEULENT phpcomta, par contre des php+mysql il y en a pas mal.
> De plus, si on doit faire PEAR:DB : il faut que dany arrète php+postgre 
> pour faire PEAR:DB directement. NON ? 

Et pour utiliser la "librairie" MySQL? Il ne va pas falloir qu'il change
ses appels à pg_query en api_db_query ou un truc comme ça?

> quel interet d'avoir phpcompta 
> avec postgre ET phpcompta avec PEAR:DB ?

Quel intérêt supplémentaire de l'avoir avec postgres et mysql?

> hervé (juste mon avis à 2 cts)

Discutons, discutons.
Les autres, si on vous embête on emporte ça hors-liste hein :-)

Yannick