On Thu, 05 Jun 2003 12:53:51 +0200, Marc SCHAEFER wrote:
> Etant un grand promoteur de PostgreSQL, je dirai tout de m�me que si la
> r�plication est en lecture seulement et une fois par jour, un simple
> dump texte de la base MySQL peut suffire.
[...]
> Si l'application n�cessite un v�ritable ACID avec support de
> transactions isol�es ou s�rialis�es en r�seau avec r�plication, je
> crains fortement que m�me PostgreSQL ne soit pas au niveau pour le
> moment (chez Oracle ce genre de chose vaut dans les 20'000 CHF par
> serveur).
IBM DB2 est beaucoup meilleur march�, et aussi beaucoup plus
conformant aux standards ouverts SQL, que Oracle. PostgreSQL est le
meilleur SGBD SQL livre d'aujourd'hui.
> Bien s�r, il y a peu d'applications qui ont besoin de telles
> fonctionnalit�s.
Je ne suis pas d'accord. Je pense que les co�ts de n'avoir
pas de transactions sont tr�s hauts. Les programmeurs ont la tendence de
pr�ferir programmer a modeller les bases de donn�es, mais les co�ts de
programmer sont hauts. Malheuresement beaucoup the gerents e utilisateus
pensent pas a les co�ts totales, mais seulement a les co�ts d'acquisition.
La integrit� des donn�es est trop important pour la laisser aux
logiciels. M�me que quelques applications n'ont pas de donn�es importants
pour les programmers, cettes donn�es seront importants pour les
utilisateurs; et il y a un co�t en plus de avoir plusieurs syst�mes de
gestion de bases de donn�es en um m�me environ, de fichiers touts simples,
a SQL. Le parfait serait d'avoir un syst�me d'exploitation relationnel,
mais si �a n'est pas possible aujourd'hui, SQL (et MySQL n'est pas
vraiment SQL) est le meilleur qui nous ont.
Il faut lire Date, et peut-�tre http://dbdebunk.com./, pour
meilleur comprener toutes ces choses...
--
Leandro Guimar�es Faria Corsetti Dutra
_______________________________________________
gull mailing list
[EMAIL PROTECTED]
http://lists.alphanet.ch/mailman/listinfo/gull
