RE: [Dolibarr-user] Abstraction de base de données e t versions de PHP

[Romain OLLIVIER]

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 address@hidden

Tél +33 (0) 610 190 056

________________________________

www.openxtrem.com 

openXtrem: Solutions open source pour les Entreprises 


-----Original Message-----
From: address@hidden
[mailto:address@hidden 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
address@hidden
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