Re: mysql et postgresql

J.Pierre Pourrez m'expliquait (le 29.07.2005 11:55):

>Le Thu, 28 Jul 2005 17:33:21 +0200, Marc BEY a écrit :
>
>
>
>>Devant nous allons mettre en place une boutique de e-commerce qui elle
>>fonctionne avec mysql.
>>
>>
>
>Et pourquoi pas Firebird qui a en plus :
> les sous-requêtes
> les procedures stockées
> une base dans un seul fichier
>
>Pour un petit site, il y a aussi SQLite3 qui semble intéressant (pas de
>procèdures stockées, mais triggers possible). A priori intégré dans
>php5 mais je n'ai pas testé.
>
>
Je réagis car « je ne suis pas d'accord ». PostgreSQL sait tout
faire (y compris du web). Il n'y a donc pas à avoir de synchronisation
de table à partir d'une autre base de données. PostgreSQL relèvera haut
la main tout les défis qu'on lui donnera et quel que soit le contexte.

>Quel langage est-il utilisé PHP, Perl, Python, Java, Bash, ...
>
>
Justement il existe des bindings pour PostgreSQL dans tous les
langages. Ne cherchez plus. PostgreSQL est là pour ça.

>>Quelqu'un a t-il des idées ou l'expérience de ce genre de choses?
>>
>>
>Le projet a-t-il un site Internet ?
>
>
Mon expérience c'est qu'il n'y a pas de meilleure solution qu'une
solution complètement cohérente. Ma réponse peut sembler incisive mais
on défend ou pas PostgreSQL (vous aurez deviné que moi je le défend).
Actuellement tout produit front-end de e-commerce doit être en
mesure de s'interfacer avec un backend database quel qu'il soit. Seule
la restriction de backend imposé par l'hébergeur (donc du mySQL) peut
justifier (et encore) la non utilisation de PostgreSQL.
Maintenant pour revenir à la problématique intiale, peut être qu'une
utilisation de SQLRelay ( http://sqlrelay.sourceforge.net/index.html
)pourrait permettre de se sortir l'épine du pied (et momentanément car
PG ferait l'affaire pour l'ensemble de la problématique, éviterait une
dispersion de la connaissance technique et architecturale et bien des
ennuis ).

Cordialement,

--
Jean-Christophe Arnu
Secrétaire PostgreSQLFr.