glpi-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Glpi-dev] Re:Lot Glpi-dev, Vol 9, Parution 3


From: alexandre\.lemiere
Subject: [Glpi-dev] Re:Lot Glpi-dev, Vol 9, Parution 3
Date: Mon, 14 Mar 2005 02:43:52 +0100

>> 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).
>
>
-------------------------
Je suis d'accord avec toi, MySQL convient trés bien à une
application comme GLPI.
Je suis aussi contre le fait de voir une version de GLPI par
SGBD. Néanmois je pense que l'idéal serait de pouvoir
permettre le choix du SGBD utilsable.
Dans mon cas, la ou je bosse c'est SQL server quasi
obligatoire(...) et d'une facon générale les gens sont
réticents à installer un 2eme SGBD.
L'intéret de ADOdb c'est justement d'avoir le meme code pour
toutes les bases, la librairie se chargeant de traduire les
instructions selon la base.
---------------

> > 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
----------------------
j'ai commencé à modifier la classe DBMySQL pour utiliser
ADOdb, avec pas ma de succès, ca ne me semble vraiment pas
poser de soucis, merci à celui qui a eut l'idée de regrouper
tous les ordres mysql dans une classe ;-)

je pars 15 jours en vacances, je m'y rattèle dés mon retour !

Accédez au courrier électronique de La Poste : www.laposte.net ; 
3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)







reply via email to

[Prev in Thread] Current Thread [Next in Thread]