[Top][All Lists]
[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