Changeset 674

Show
Ignore:
Timestamp:
08/17/07 11:52:58 (1 year ago)
Author:
kryskool
Message:

première partie surement en conflit avec ioguix :'(

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • materials/advocacy/trunk/Why_PostgreSQL_Instead_of_MySQL.txt

    r673 r674  
    1 Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007 
     1//Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007 
     2Pourquoi PostgreSQL plutôt que MySQL : Comparaison de la fiablité et rapidité en 2007 
    23 
    34Introduction 
    45 
    5 For years, the common industry perception has been that MySQL is faster and easier to use than PostgreSQL. PostgreSQL is perceived as more powerful, more focused on data integrity, and stricter at complying with SQL specifications, but correspondingly slower and more complicated to use. 
     6//For years, the common industry perception has been that MySQL is faster and easier to use than PostgreSQL.  
     7//PostgreSQL is perceived as more powerful, more focused on data integrity, and stricter at complying with  
     8//SQL specifications, but correspondingly slower and more complicated to use. 
     9Pendant des années, la perception du marché était que MySQL était plus rapide et facile à utiliser que PostgreSQL. 
     10PostgreSQL est perçu comme étant plus puissant, focaliser sur l'intégrité des données, et plus respecteux des normes 
     11SQL, mais également plus lent et plus compliqué à utiliser. 
    612 
    7 Like many perceptions formed in the past, these things aren't as true with the current generation of releases as they used to be. Both systems have evolved with landmark releases that make comparing the two a lot more complicated. 
     13//Like many perceptions formed in the past, these things aren't as true with the current generation of releases as  
     14//they used to be. Both systems have evolved with landmark releases that make comparing the two a lot more complicated. 
     15 
    816 
    917    * MySQL 5.0 (October 2005) finally added a "strict mode" to narrow the gap in terms of data integrity and spec compliance. It also added support for stored procedures, views, triggers, and cursors, all considered essential features for some classes of database deployments.