/* English speakers there an english version at the end of the mail */
Nous écrivons ce mail pour clarifier la politique globale de l'équipe de
développement au sujet de la problématique des SGBD et GLPI.
Etat de la base de données de GLPI :
Actuellement la base de donnée de GLPI contient 63 tables pour un total
de 467 champs.
Dans le temps la base de donnée va être amenée à évoluer vers un modèle
de plus en plus complexe.
De part les configurations actuelles et la relative petite taille des
parcs gérés par les utilisateurs (voir la section références sur le site
du projet), la structure physique MyISAM de Mysql suffit largement pour
les besoins globaux de GLPI.
Si les conditions d'utilisations devaient en rester là, nous sommes
d'accord pour dire qu'il serait plus que profitable au projet d'ajouter
une couche d'abstraction des données telle qu'adoDB, ou PEAR:db.
La raison pour laquelle ces couches d'abstraction ne nous intérressent
pas c'est parce que les conditions d'utilisation n'en resteront pas là :
Dans un futur plus ou moins proche, nous allons être confronté à
plusieurs problèmes :
- La structure de la base de données va devenir de plus en plus
complexe et le nombre de requêtes à l'utilisation va augmenter
exponentiellement en fonction de l'ajout de fonctionnalité.
- Nous allons voir arriver des utilisateurs gérant des parcs très
conséquents (des dizaines de milliers de postes avec une hierarchie de
sites distants complexes).
Pour faire face à ces problématiques la base de données devra évoluer
vers un modèle plus cohérent assurant un maximum d'intégrité des données.
La solution vient d'elle même, il faudra passer vers une structure
physique plus adaptée, en intégrant complétement des principes tel sque
les triggers, procédures stockées, vues et autres concepts gérés par le
SGBD lui même.
Ceci imposera à GLPI d'être lié à un SGBD particulier, il nous reste à
statuer vers quelle solution nous allons converger, la contrainte
majeure étant que ce SGBD devra être libre sous une licence compatible
avec la GPL, mais devra aussi être intégrable facilement pour les
petites structures n'ayant pas des besoins aussi importants que les trés
grosses structures utilisant GLPI.
Pour résumer, nous souhaitons utiliser un SGBD intégrant des mécanismes
puissants de traitement, tout en restant très simple et surtout facile
d'accès (packaging, intégration dans les systèmes d'exploitation
existants...).
Ceci en tête nous attendons avec impatience l'arrivée de MySQL 5, qui
nous semble répondre parfaitement à ces besoins et contraintes.
Ceci dit ce n'est pas une position fixe, et il est toujours bon d'en
discuter et d'avoir l'avis de chacun.
De toutes façons tout cela n'est pas pour tout de suite, puisque dans un
premier temps nous avons beaucoup d'autres aspects en matière de
fonctionnalités à régler.
Nous sommes prêts aussi à donner un peu de notre temps et éventuellement
mettre à disposition des outils et une infrastructure aux personnes
souhaitant faire des migrations de ce type (en intégrant les concepts de
triggers, procédures stockées, vues etc...) vers PostgresSQL ou d'autres
SGBD libres.
Nous avons statué d'un commun accord et après de longues discussions que
l'utilisation de couche d'abstraction, ou la migration telle quelle
(sans réel changement dans le modèle physique des données, ni
utilisation des outils fournis par le SGBD) n'apporterait rien sur le
long terme au projet.
Au contraire, cela serait même en contradiction avec nos perspectives
d'évolution dont les raisons sont citées plus haut.
Bien sûr ceci est l'avis de l'équipe de développement, nous attendons
vivement des réactions argumentées de la part de tous nos utilisateurs
se sentant concernés.
--
L'équipe de développement de GLPI.
---/* English version This is an automatic translation, sorry for the
bad english used here. */-------------
We write to this mall for clairifier the overall policy of the team of
development about the problems of the DBMS and GLPI.
State of the data base of GLPI:
Currently the GLPI database contains an about sixty tables for
a total of 467 fields. In time the base of data will be brought to
evolve to an increasingly complex model.
In majority of the current configurations and relative the small size
of the parks managed by the users (see the section references on the
site of the project) the physical structure MyISAM from Mysql is enough
largely for the global needs for GLPI.
If the conditions of use would stay in this state, we agree for saying
that it would be more than advantageous with the project to add a
layer of abstraction of the data such as adoDB, or PEAR:db. The reason
for which these layers of abstraction do not interressent us it is
because the conditions of use will not stay in this state :
In a more or less near future, we will be confronted with several
problems:
- the structure of the data base will become increasingly complex
and the number of requests to the use will increase exponentially
according to the addition of functionality.
- We will see users managing very big parks (more than 20 000
stations on a hierarchie of distant sites).
To face these problems the database will have to evolve to an adapted
model ensuring a maximum of integrity for the data.
The solution come from it, it will be necessary to pass towards
more adapted physical structure, by integrating complétement
principles such as the triggers, stored procedures, view and other
concept managed by the DBMS him even.
This will force GLPI to be related to a particular DBMS, it remains us
to be ruled towards which solution we will converge, the major
constraint being that this DBMS will have to be free under a licence
compatible with the GPL, but it will have also to be integrable easily
for the small structures not having as important needs as the
large structures using GLPI. To summarize we wish to use a
DBMS that make working the mechanisms of powerful treatment, while
remaining for basic configurations very simple and especially easy of
access (packaging, integration in the existing operating systems...).
This at the head we wait with impatient the arrival of MySQL
5, which seems in our mind, to answer perfectly these needs and constraints.
This it is not a fixed position, and it is always wise to discuss
it and to have the opinion of each one.
In any case all that is not for immediately, for now we have
much of other aspect as regards functionalities to regulate.
We are available also to give a little our time and if required to put
at disposal tools and an infrastructure to the people wishing to
make migrations (by integrating the concepts of trigger,
procedures stored, view etc...) towards PostgresSQL or other free DBMS.
We ruled by mutual agreement and after a long discuss that
the use of layer of abstraction, or the migration just as it is
(without real change in the physical model of the data, nor use of the
tools provided by the DBMS) will not bring anything on the long term
to the project, and on the contrary will be even in contradiction with
our prospects for evolution whose reasons are quoted higher.
Well on this is the opinion of the team of development, we highly
await reactions argued on behalf of all our users feeling concerned.
--
The development team.
