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
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-user
_______________________________________________
Dolibarr-user mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/dolibarr-user
