dolibarr-dev
[Top][All Lists]
Advanced

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

Re: [Dolibarr-dev] proposition de passage a PEAR::DB


From: Eric Seigne
Subject: Re: [Dolibarr-dev] proposition de passage a PEAR::DB
Date: Wed, 15 Jan 2003 13:48:16 +0100
User-agent: Mutt/1.4i

On Wed, Jan 15, 2003 at 12:35:59AM +0100, Rodolphe Quiedeville wrote:
>> Si vous m'autorisez à faire un rush de quelques jours pour faire une
>> branche dolibarr-pear dans le CVS, je peux essayer de faire le
>> travail, je ne promets rien mais au moins ça m'occupera
>
>Hummm pas trop chaud pour une autre branche, concentrons-nous d'abord
>sur les fonctionnalite.

ok

>Quelles sont tes motivations profondes au fait pour PostgresQL au lieu
>de Mysql ?

que je n'ai pas de mysql sur mes  serveurs :) et que ça me tue un peu de
devoir installer un  second moteur de base de  données, de l'administrer
et de  le voir me  bouffer mes maigres  ressources ... sans  compter les
classiques reproches qu'on fait à mysql :o)

Par  exemple,  ça me  dérange  beaucoup de  me  rendre  compte que  pour
dolibarr on  a pas de schéma de  base de données, pas  de contraintes au
niveau base de données et je suis persuadé qu'on vas se trouver dans une
situation du style
 - un développeur "nouveau" propose un module de gestion de xxxxx
 - tout le monde est enchanté, on l'utilise et c'est cool
 - dans son module il  propose d'effacer des enregistrements, disons par
   exemple qu'il gère le stock, et dans sa gestion du stock il gère donc
   les fournisseurs, et il a codé un truc qui efface le fournisseur dans
   un cas particulier qui est cohérent dans son analyse du module
 - mais c'est pas cohérent par rapport à l'application globale
 - le module  de suivi des payements  se trouve avec une  référence à un
   fournisseur qui n'existe plus

 -> comment on fait ?

Alors que si  on se base sur un  moteur de base de données  qui gère les
contraintes  d'intégrités et  les clefs  externes,  et qu'on  a un  beau
schéma de base de données avec toutes les relations c'est impossible, le
programmeur  décide de  supprimer  un  fournisseur, libre  à  lui de  le
demander, mais la BDD lui  retournera "non coco c'est interdit, la table
association_adherents_fournisseurs y fait référence" ...

D'ou mon  choix clair,  tranché et net  pour PgSQL dans  une application
aussi  crutiale  pour  mon  entreprise  que  la  gestion  des  factures,
contacts, payements, fournisseurs, stock et tout ce qu'on peut imaginer.

>> (c'est soit ça soit aller participer au ramassage du fioul du
>> prestige sur les plages de ma commune) ...
>
>Bonne idee ca ;-)

Vi ben finalement,  j'ai pas encore été le  faire, à court d'équipements
qu'ils étaient ici ... j a pas eu ma belle combinaison blanche !

a+
Éric




reply via email to

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