Avez-vous déja une idée sur la "librairie d'interfacage" la plus
efficace et complète pour la base de donnée ?
pearDB, ADO, ou encore méta(chépluquoi) ?

nicodache

On Thu, 31 Mar 2005 05:39:43 +0200, DJ Anubis <[EMAIL PROTECTED]> wrote:
> Le Mercredi 30 Mars 2005 22:14, Benoit Mortier a écrit :
> 
> > Cela me semble bizarre d'entendre qu'une application ne supporte qu'une
> > database ;-)
> :-)
> 
> > 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.
> 
> A moins d'aimer les usines à gaz avec des batches pour tenter de rendre
> interopérables des applications. Glpi étant une gestion de parc informatique,
> il s'agit d'un produit destiné à des entreprises ou groupes possédant un parc
> suffisant pour nécessiter une telle gestion.
> Dans ce cas, forcer l'utilisation d'un SGBD particulier risque de provoquer le
> rejet pur et simple du soft par les administrateurs SGBD.
> 
> > > 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.
> 
> Il existe une règle simple qui permet d'éviter les mots réservés dans les noms
> de colonnes, préfixer tous les champs des tables. Par exemple, une table
> contacts voit ses champs préfixés par ctc_.
> 
> Attention également au champ ID. C'est un mot réservé avec Ovrimos, comme OID
> avec PostgreSQL. En ayant examiné une soixantaine de SGBD, ous en sommes
> venus à "recid" comme champ primary key, celui-ci n'étant utilisé par
> personne.
> 
> Les plaisirs de la portabilité commencent ;-)
> 
> --
> JCR
> aka DJ Anubis
> LAB Project Initiator and coordinator
> 
> 
>

Reply via email to