Bonjour, Je ne suis pas sur de comprendre la relation entre "quels sont les avantages/inconvénients des différentes bases de données" et "faut-il utiliser une couche d'abstraction de base de données"...
>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' Si PHPCompta utilisait une couche d'abstraction, tu l'aurais adopté 'de suite', de même que l'utilisateur d'Oracle, d'SQL Server, ... Je pense moi que puisque les bases de données ont toutes des fonctionnalités et des performances différentes, une couche d'abstraction est indispensable. Cela peut demander une couche de vérification d'intégrité des données optionnelle dans le cas ou l'appli a été développé initialement sous Oracle ou Mysql InnoDB qui les gèrent déjà, et pour les sytèmes la prennant déjà en compte (systèmes créés initialement sous Mysql MyISAM), tout fonctionnera comme sur des roulettes quelle que soit la base de données. -- Romain OLLIVIER Consultant - Expert SIH et systèmes web open source Email [EMAIL PROTECTED] Tél +33 (0) 610 190 056 ________________________________ www.openxtrem.com openXtrem: Solutions open source pour les Entreprises -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of herve couvelard Sent: jeudi 13 avril 2006 10:57 To: Discussions sur l'utilisation de Dolibarr Subject: Re: [Dolibarr-user] Abstraction de base de données et versions de PHP Dany De Bontridder a écrit : > On Wednesday 12 April 2006 10:47, Thomas Despoix wrote: > >> Bonjour Hervé, >> >>Je n'ai pas pu lire tous les messages mais je voulais juste réagir à la >>question MySQL ou PostGreSQL. Pourquoi ne pas utiliser PDO qui est la >>nouveauté majeur de PHP 5.1 ? > > Je me demande si l'indépendance par rapport à la base de données est une si > bonne chose: cela nous oblige à gérer l'intégrité dans l'application et alors > le moindre bug se traduit par une incohérence dans les données. Donc un peu > dangereux surtout quand on sait que la compta est destiné à être épluché par > un contrôleur. Bonjour Dany.. bonne question philosophique au réveil. . . . Je ne suis pas un spécialiste BDD mais je travaille avec depuis 1995, d'abord ACCESS (pas taper pas taper) puis j'ai commencer sur le web en 1998 avec les prémisses de viva-vous.net. A ce moment j'ai fait un tour de ce qui se faisait et j'ai fait le choix de Msql car il/elle était porté(e) par une entreprise commerciale et qu'elle correspondait exactement à mes besoin : un vitesse brute comme critère de conception en laissant aux applications le controle de l'intégrité. Pour être de mauvaise fois je ferais la comparaison avec windows qui demande 25 fois si on est sur de vouloir effacer ce fichier. Viva-vous.net géoclasse à la volée (CAD à chaque requette) plus de 600 000 adresses il affiche les bannières dans un contexte géolocalisé à la commune(cad que la personne de nice ne verra pas les même bannières que celle de lille, ni celle de roubaix). Viva-vous.net sert environs 3 milllions de pages par an (dont pratiquement aucune statique) avec des pointes à plus de 15 000 page par jour sans que l'on ne ressente un a-coup d'attente des pages. Viva-vous est hébergé sur un dédié virtuel avec entre autre esp-vi.com et cegeb.com, une application destinée aux experts forestiers de gestions de forets qui a des fonctionnalités intéressante, génération automatique de document Ooo en tri de BDD, embryon de cartographie intéractive en SVG, calcul de rentabilité et 'bilan' financier des parcelles (groupes de parcelles, forets) sur différente périodes, suivi des travaux fait/a_faire, outil de communication entre les intervenants avec gestion des droits de chacun etc.... Cette vélocité est due au fait que Mysql ne se pose pas de question et fait ce qu'elle a à faire. Ce ne serait pas possible (avec les même ressources matérielles) de le faire avec un oracle ou un postgresql. Ok, je dois être très prudent lors de la programmation car JE gère l'intégrité des tables et une erreur de ma part : "hop ... nické" (tm). Mais je considère que c'est mon travail de programeur/chef de projet/ce_que_tu_veux de gérer cette intégrité. OK je suis le seul qui travaille sur ces projets (et j'ai toujours été le seul), ce qui me permet d'assurer l'intégrité. Dans le cas d'une comptabilité, il y a peu d'intégrité à gérer tout est dans le style : achat 30 tva 3 banque 33 le pire que tu peux faire est d'effacer un compte dans ton plan comptable et donc de laisser des écritures orphelines. MAIS cela dépend aussi de ton select. Par exemple : "select *.ecritures, id.comptes, numero.comptes from ecritures, comptes where id_compte.ecritures=id.comptes" te laisse en plan toutes les écritures avec un compte effacé" MAIS "select *.ecritures, id.comptes, numero.comptes from ecritures LEFT JOIN comptes ON id_compte.ecritures=id.comptes" te font apparaitres des écritures orphelines avec NULL dans numéro.comptes, ce qui peut te permettre de rectifier le coup SANS perte de prrformance si tes indexes sont positionnées comme il faut. Donc, l'argument de l'intégrité est moins déterminant que l'on veut bien le penser, et c'est une discussion que j'enfourche facilement,[peut être l'age]. Pour donner un peu plus de poids à mon argumentation (arrrfff), (coup bas désolé) c'est ton statut de free lance Oracle qui te pousse à travailler avec un char d'assaut (au cas ou) pour aller ceuillir des paquerettes. :-) L'évolution de mysql (et MYSQL AB) me conforte chaque jour dans mon choix de 1998 (lorsque j'ai choisi de me 'marrier avec'). 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. Voila, l'évolution de mysql qui ajoute des fonctionnalités à la Oracle et postgre devrait dans un avenir proche voir une migration des nombreuses personnes de oracle vers mysql, en laissant à oracle son marché NATUREL : le besoin d'une BDD sécurisé à la colone et à la ligne, avec la possibilité de faire plein de choses avec des vues graphiques au détriment de la performance brute. Par exemple lorsque je fais un essai sur le site phpcompta de demo en ligne base compta cvs /journaux/grandlivre/, il y a un 'blanc' de 5-9 secondes, je ne l'accepterais jamais d'une de mes applications. Mais je continue à dire que php compta est une super appli, et ce ne serais pas sous postgre, je l'aurais adopté 'de suite' Voila . . . mais je suis partant pour des dicussions sur ce thème. hervé _______________________________________________ Dolibarr-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-user -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date: 11/04/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.1/309 - Release Date: 11/04/2006 _______________________________________________ Dolibarr-user mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-user
