Re: [Dolibarr-user] Abstraction de base de données et versions de PHP

[herve couvelard]

> 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é