[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Dolibarr-user] Abstraction de base de données et versions de PHP
From: |
herve couvelard |
Subject: |
Re: [Dolibarr-user] Abstraction de base de données et versions de PHP |
Date: |
Thu, 13 Apr 2006 10:57:24 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20051002) |
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é
- Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, (continued)
- Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, Philippe Rousselot, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, Dany De Bontridder, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, Philippe Rousselot, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, Alex, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, Christophe Battarel, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, Philippe Rousselot, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, PIERRE de GEYER Cyril, 2006/04/11
- Re: [Phpcompta-contrib] Re: [Dolibarr-user] Synergie Dollibar - PHPCompta, herve couvelard, 2006/04/12
- [Dolibarr-user] Abstraction de base de données et versions de PHP, Thomas Despoix, 2006/04/12
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Dany De Bontridder, 2006/04/12
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP,
herve couvelard <=
- RE: [Dolibarr-user] Abstraction de base de données e t versions de PHP, Romain OLLIVIER, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, herve couvelard, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Thomas Despoix, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, herve couvelard, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Christophe Battarel, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, herve couvelard, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Marc Barilley, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Thomas Despoix, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Marc Barilley, 2006/04/13
- Re: [Dolibarr-user] Abstraction de base de données et versions de PHP, Christophe Battarel, 2006/04/13