Le Mercredi 30 Mars 2005 17:37, [EMAIL PROTECTED] a écrit : > > Bonjour/soir à tous, > > > > Je suis actuellement en train de porter GLPI sous PostGreSQL (nous > > utilisons PostGre partout, sauf pour GLPI, nous souhaitons donc porter > > GLPI sous PostGre pour faciliter l'administration de tout ce que nous > > utilisons). > > Comme j'ai déjà eu l'occasion de le dire sur cette mailing liste, à mon > avis pour qu'un portage de GLPI sous postgreSQL ou sur d'autres sgbd > valent vraiment la peine il faudrait recoder la majeure partie de > l'application.
Cela me semble bizarre d'entendre qu'une application ne supporte qu'une database ;-) > Je comprend les problématiques d'intégrations inhérentes à vos solutions > packagées, mais, a priori, nous ne les partageons pas. Il ne sagit pas de solutions integrées, mais de logique ... je vois mal un administrateur système faire tourner 3 moteurs de database differents pour 3 programmes différents. Il va donc essayer de tout faire tourner sur le même moteur de database > > Bien sur, cela ne va pas sans mal, MySQL ayant quelques particularités. > > > > Au rang de ces dernières, le dernier problème qui me titille, le champ > > user de la table glpi_prefs. Il semblerait en effet que le mot user > > soit un mot réservé de SQL92, ou du moins de PostGreSQL. > > Je souhaite donc savoir si vous avez un souhait particulier pour le > > changement des noms de colonnes dans la base de donnée (je > > répercuterai bien sur les changements dans le code), ou si la simple > > traduction en francais (utilisateur) vous va. > > Dans l'absolu si on touche a cette partie autant changer le champs user > en integer, en l'appelant FK_glpi_users et faire la jointure entre > glpi_users.ID et glpi_prefs.FK_glpi_users. ok > Si néanmoins vous ne vous sentez pas de faire ça, je pense que "username" > ou "glpi_username" est mieux que "utilisateur". ok on verra ce qui est le plus simple pour l'instant ;-) A+ -- Benoit Mortier Linux Engineer www.opensides.be
