Re: [Glpi-dev] porter GPLI vers un autre SGBD

[baaZ]

alexandre.lemiere a écrit :
> Bonjour la liste,
>
> j'étudie la possibilité de porter GPLI vers d'autres SGBD,
> probablement par l'utilisation de la couche d'abstraction
> ADOdb  http://adodb.sourceforge.net/ .
>
> Qu'est-ce que vous en pensez ?
> Est-ce qu'un tel projet existe déja ?
>
> En regardant (vite fait) le code j'ai vu la classe DBmysql
> dans common/classes.php. Tout ce qui concerne la connection et
> les requetes est la ? 


La question que je me pose c'est pourquoi porter GLPI sur un autre SGBD ?

Je pense que Mysql suffit largement aux besoins de l'application, je 
pense même que d'un point de vue d'architecture c'est le SGBD le plus 
adapté à ce qu'on fait.

Il serait possible (pour postgres par exemple) d'ecrire une classe 
DBPostgresSQL et ça prendrai tres peu de temps vu que l'API 
php->postgres est quasiment aussi complete que l'API php->mysql.

Mais, à l'heure actuelle GLPI n'est pas fait pour fonctionner sur un 
SGBD relationnel, les jointures et les contraintes d'intégrité sont 
assuré en dur dans le modèle et dans le code.

Cela suffit amplement vu le relatif petit nombre de requetes et de 
traitements, meme sur des parcs jugés de bonne taille (1000 à 1200 postes).

De mon point de vue, un portage vers Postgres (par exemple) ne serait 
interressant que si l'on changeait completement le modèle physique de la 
base de donnée, et beaucoup de parties du code.

Ensuite on se retrouverai avec "deux" GLPI différents un pour Mysql et 
un pour Postgres, ça ne me semble pas envisageable, et peu interressant 
vu ce qu'on a à y gagner.

Sachant cela je ne vois pas trop quel est l'interet d'avoir une base sur 
postgresSQL ou autre alors que le modèle a été pensé et optimisé pour 
fonctionner sur MySQL (en myISAM)...
L'application y perdrait forcement au niveau performances.

MySQL est déployable sur la plupart des environnements, c'est un SGBD 
libre (bien que sous double licence pour certaines utilisations, mais 
même dans ce cas là le prix est vraiment accessible).


> est-ce que creer une nouvelle classe DBadodb serait une
> solution simpliste ?
>

Je ne me suis pas assez penché sur les sources d'adodb pour pouvoir dire 
que ce serait facilement portable de cette façon.

--
Bazile