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

[herve couvelard]

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é