herve couvelard a écrit :
Pas tout à fait d'accord avec toi. Les couches d'abstraction ne sont pas que des sur-capsules pour s'abstraire du type de la base de données, en ne sélectionnant que l'intersection -- sous-entendu le sous-ensemble pauvre -- des fonctionnalités de chacun des moteurs. Ce sont également des outils pour structurer et sécuriser les accès aux bases de données, en préparant les requêtes et les mettant en cache, etc.La couche d'abstraction est une solution moins pire que pas compatible du tout MAIS elle implique une perte de performance et une dépendance à la couche d'abstraction qui est un facteur exogène supplémentaire. Celui qui développe un soft,le fais pour un environnement particulier.Maintenant ;-) :-) ;-) chacun a raison d'avoir raison et personne n'a la vérité, ET je partage entièrement ton AVIS : PAS DE COUCHE D'ABSTRACTION.Justement, si chacun a raison d'avoir raison, il FAUT utiliser des couches
d'abstraction dans les systèmes pour que tout le monde puisse continuer
d'avoir raison !
Mais je continue à dire que php compta est une super appli, et ce ne serais pas sous postgre, je l'aurais adopté 'de suite'
Une chose est sûre, si on utilise les API MySQL (ou autre) fournies pour PHP sans faire ce genre de travail amont, le système devient une vrai passoire aux injections de code SQL. N'importe quel petit utilitaire de cracking prend le contrôle de la base en 5 secondes, et de façon automatique. J'ai vu de mes yeux Rasmus Lerdorf (inventeur de PHP) 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.
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. En tout 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é.
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.
Laquelle erreur de conception serait probablement gommée par l'utilisation de la fameuse intersection de fonctionnalité. Du reste je 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.
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.
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...
--
Thomas Despoix
Expert Web Open Source
tél: +33 (0) 662 199 661
email: address@hidden
openXtrem: Solutions Open Source pour les Entreprises
Thomas Despoix
Expert Web Open Source
tél: +33 (0) 662 199 661
email: address@hidden
openXtrem: Solutions Open Source pour les Entreprises