A mon tour de sauter dans le troll :-)
Etant donné la cible à laquelle s'adressent Dolibarr et PHPCompta, à
savoir les PME/PMI voire les travailleurs indépendants (seuls), il est
évident que la question qui se pose n'est pas de savoir s'il faut
choisir le SGBD le plus performant pour la tâche mais plutôt celui
dont dispose l'utilisateur potentiel. Une PME/PMI ne veut pas
s'investir dans un serveur dédié, même en location. En effet, elle n'a
généralement pas les compétences internes pour gérer un serveur et
s'enquiquiner avec la gestion des DNS, la configuration de son Apache,
le renouvellement de son nom de domaine, le maintien de son SMTP/POP
et j'en passe et des meilleures. Si en plus, elle doit prendre un
consultant même ponctuellement pour gérer tout ça, avec un délai
d'intervention souvent (trop) long, c'est hors de propos. Cela
augmente son budget de manière beaucoup trop importante. Elle va donc
se tourner vers un hébergement mutualisé standard.
Alors quel est ce SGBD ? Un rapide tour d'horizon montre que les
hébergeurs proposent des solutions dont les caractéristiques sont
grosso modo :
- MySQL 3.23 à 4.1
- PHP 4.0 à 4.3
Plus rarement, on a MySQL 5 et PHP 5. Certains proposent également
PostgreSQL mais ils sont tout aussi rares.
La réponse est donc toute trouvée : puisqu'il faut rester compatible
et utilisable avec au moins 80% du marché (viser en dessous de 80% est
assez ridicule, à mon avis), il faut tourner sur un MySQL 3 avec PHP
4. Ca tombe bien, c'est ce que Dolibarr sait faire.
Concernant PHPCompta, je ne connais pas le soft, je ne m'exprimerai
donc qu'avec parcimonie à son sujet. Si l'auteur souhaite continuer à
tourner sur PostgreSQL, pourquoi pas, c'est son choix. Mon avis est
qu'il se coupe d'un marché potentiel et cela plaide donc en faveur des
couches d'abstraction.
Parlons de ces couches. Après en avoir utilisé plusieurs, je constate
qu'elles présentent toutes plus ou moins les mêmes fonctionnalités,
lesquelles ne sont pas le sous-ensemble le plus pauvre des SGBD
supportés, loin de là. Mais évidemment, cela coupe d'un certain nombre
d'extensions propres à chaque SGBD. Et alors ? Si on ne peut vraiment
pas s'en passer, c'est que l'algorithme qui tourne derrière à un
problème quelque part, à mon avis. Au pire, on les émule (ok, je sens
venir le couplet sur les performances et tout ça, mais j'en parle plus
bas ;-)). Tiens, par exemple, PostgreSQL propose des curseurs pour
naviguer dans les résultats d'une requête mais pas MySQL. Eh bien, je
sais pas pour vous, mais moi ça me prend environ 15 minutes pour coder
un système de cache et j'ai l'équivalent d'un curseur PostgreSQL sur
MySQL. Et côté performances, je ne suis même pas sûr d'être perdant.
Tout ça pour dire que je trouve ces couches très pratiques.
Personnellement, rien ne m'horripile plus que, par exemple, de me
demander comment on échappe les caractères en fonction du SGBD que
j'ai en dessous. Et j'en passe et des meilleures. Et là, je remercie
la couche d'abstraction.
D'une manière générale, il me semble évident de séparer les
fonctionnalités en couches successives. Pour moi, un code métier (la
CRM de Dolibarr, la compta de PHPCompta), ni même sa couche de
stockage, ne devrait contenir aucune requête SQL. Les requêtes
devraient être encapsulées dans des procédures stockées. Du coup, même
la partie la plus basse de la couche métier est indépendante de la
structure de la base de données, et à fortiori du SGBD lui-même. De
même pour l'affichage (et je lance un autre troll) qui devrait être
géré par un système de template. Résultat : séparation totale du
stockage, du calcul et de l'affichage. Dans l'absolue, la
communication entre les couches elle-même devrait être encapsulée.
Tout ça amène à une indépendance totale des composants de
l'application. Et du coup, facilite grandement l'intégration et
l'interaction des applications.
En effet, on pourrait très bien imaginer changer simplement la couche
de stockage de Dolibarr (actuellement, MySQL) par PHPCompta. Oui,
PHPCompta, pas juste la base de données de PHPCompta, le logiciel
entier. Ou l'inverse. Il "suffirait" d'avoir une interface (au sens
programmation) qui permette d'interroger PHPCompta pour remplir les
écrans de Dolibarr et une autre pour sauvegarder dans PHPCompta les
actions faites par l'utilisateur sur Dolibarr. Ou l'inverse. A ce
sujet, les triggers de Dolibarr sont déjà des prémices très
prometteurs (bravo Eldy). Ne reste qu'à en étendre le champ
d'application.
C'est bien beau tout ça mais c'est de la théorie. Et les performances
? Réponse : quelle importance tant que ça reste raisonnable. Aucun de
ces deux logiciels n'a vocation à traiter 40000 hits par seconde. Tout
au plus, lorsque les 4 commerciaux de la société qui utilise ces deux
logiciels travaillent en même temps, on atteint des pics de 30 pages
demandées par minute. Alors les performances... pfff... Ces mêmes
commerciaux sont tellement habitués à attendre parfois 5 secondes pour
obtenir une page web avec les derniers cours de la bourse que ce n'est
pas ça qui va les empêcher d'utiliser Dolibarr ou PHPCompta.
Le jour où Dolibarr et PHPCompta seront tellement répandus qu'ils
remplaceront tous les autres logiciels du marché, qu'ils auront
conquis même les grandes entreprises où plusieurs centaines ou
milliers d'utilisateurs seront connectés dessus en permanence, alors
ce jour-là les ordinateurs (quantiques ?) et les réseaux auront
suffisamment évolué pour encaisser la charge ;-)
Voilà, c'est mon avis, et je le partage (comme il est coutume de dire)
Marc Barilley
Océbo
herve couvelard a écrit :
utiliser son fameux 'scanmus' pour agresser les sites marchands
français à la conférence PHP Paris 2005 : c'est totalement
effrayant... A ce moment là, les performances deviennent le cadet
des soucis.
Non la performance passe après la sécurité car personne ne ferait des
courses sur un site marchand qui met 15 secondes a afficher chaque
page, quand bien même se serait ultra-sécurisé. De plus si ses sites
marchands avaient développer leur propre code, le scanmus se serait
cassé les dents.
Pour parler des performances justement : j'imagine que tes
applications sont au minimum sécurisées, donc tu as produit ce
fameux code (échappements de caractères, traitement d'erreur, etc.).
Les couches d'abstraction comme PEAR::DB ne font finalement que ce
genre de traitements supplémentaires, et souvent de façon très
optimisée.
Non les couches d'absraction ne font pas QUE ce genre de traitement
complémentaire, il gère à CHAQUE requette le choix de la base de
donnée. ils doivent, j'imagine, implémenter EN PROPRE certains
fonctionnalités qui ne sont pas commune aux base de données.
Par ailleurs, je ne fais du traitement d'erreur que lorsque cette
erreur à une incidence durable et importante, soit très rarement (sur
viva par exemple très très peu d'écriture).
Si cétait juste une couche de sécurisation, il suffirait de lancer un
sed -e 's\mysql\pgsql\g' sur la totalité de l'arborescence.
cas incomparablement mieux que si on espère réinventer la roue. Le
cas de PDO est encore plus flagrant, car ce code est exécuté dans
une extension compilée avec une performance inégalable en code PHP,
fut-il en byte-code optimisé.
oui mais PDO est php5 only.
Pour ce qui est des comparaisons de performance entre les
différentes bases de données : si une application met 5-9 secondes
pour réagir sur une altération standard, i.e. qui arrive souvent,
cela vient plus souvent d'une erreur de conception que d'une lenteur
du moteur de SGBD. PostGre est effectivement moins rapide que MySQL,
mais on reste dans le même ordre de grandeur : on ne passe pas du
quasi-instantané, quelques dizaines de millisecondes, à presque une
dizaine de secondes, c'est-à-dire 100 fois plus.
c'est pas beaux de taper sur dany : c'est son code qui met ce temps. ;-)
je ne sais pas de quoi cela provient, mais les .jsp, .cfm sont
TOUJOURS plus lent que les .php sur le net. Oracle a besoin d'une
architecture matérielle plus étoffée que mysql. Maintenant je n'ai
pas travaillé avec pgsql, mais il est EVIDENT que plus on analyse une
requete pour faire des vérifications d'intégrité, plus la requette
est lente. [ne serait-ce que pour faire cette vérification].
Laquelle erreur de conception serait probablement gommée par
l'utilisation de la fameuse intersection de fonctionnalité. Du reste je
oui la BDD du pauvre, comme le compte bancaire universel ou la carte
plastique de retrait mono guichet qui ne peut pas servir à payer
(sécurité optimale).
L'intersection de fonctionnalité ne sert qu'a ceux qui essaient de
'ratisser le plus large possible' au détriment des performances. une
application pro n'est ni un cours de développement pour débutant (cad
facile à lire et comprendre avec des commentaires de code
pantagruelique, ni une proof of concept de l'universalité
d'environnement.
te rejoins totalement sur l'intégrité référentielle, même si
j'aimerais avoir un filet supplémentaire grâce aux foreign keys.
ces vérifications externes, j'ai connus avec access, non merci.
Pour info, et sans vouloir faire de surenchère, notre application
(système d'information hospitalier) effectue sans problème de
performance (réponse quasi-instantannée) 3 millions de requêtes pour
50 mille pages servies par jour. Avec un processeur dont les pics de
charge dépasse rarement 20% sur un lissage de 5 minutes.
il est seul sur son serveur ou est hébergé chez un dédié virtuel (et
donc partagé avec d'autres dédié virtuel) ?
Une requette n'est pas forcement identique à l'autre, la partie
"lourde" de viva c'est le géoclassement : chaque adresse est triée
par rapport à la commune du visiteur, on doit calculer les distances
pour chaque enregistrement et pour chaque requette, et il est
impossible de mettre des résultats en cache car chaque visiteur vient
d'une ville différente.
Si j'ai cité ce cas, ce n'est pas pour en avoir une plus grosse,
c'est parce que c'est un cas très particulier. Ce n'est pas trouver
la liste des produits qui appartiennent à la catégorie 1 ou de sortir
le dossier d'un patient avec toutes ses visites passées (par exemple)
Mot de la fin concernant le facteur exogène, ces couches
d'abstraction des surtout des standard de facto, qui font que
n'importe qui entrant dans de code s'y retrouvera d'autant plus
vite, sans avoir à effectuer sa propre rétro-ingénierie.
oui, on en revient , je sais suis un peu tétu, à pourquoi pas une
surcouche sur le langage, cela permettrait aussi a celui qui ne
connait pas php de s'y retrouver plus vite... nan je rigole.
Si une personne veut coder comme il faut avec ces méta-couches
d'abstraction, il doit d'abord faire de la rétro-ingénierie sur le
code de ces couches, sinon, je ne donne pas chère du code fini. les
codes php de 50 lignes qui refont ce qu'une ou deux fonction font
déja, je l'ai vu
un nombre incroyable de fois.
Je peux comprendre qu'une entreprise commerciale développe en
abstraction, ce qui lui permet de 'proposer' ses produits quelque
soit l'environnement de travail de ses prospects/clients, mais
certains prefèrent coder nativement (sacrifiant la portabilité il est
vrai) pour bénéficier des fonctionnalités et des performances de
celle qu'elle a choisie.
hervé
_______________________________________________
Dolibarr-user mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-user
_______________________________________________
Dolibarr-user mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/dolibarr-user