Changeset 688

Show
Ignore:
Timestamp:
08/29/07 23:09:43 (1 year ago)
Author:
ioguix
Message:

Chapitre "Transactionnal DLL"

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • materials/advocacy/trunk/Why_PostgreSQL_Instead_of_MySQL.txt

    r686 r688  
    1313//Like many perceptions formed in the past, these things aren't as true with the current generation of releases as  
    1414//they used to be. Both systems have evolved with landmark releases that make comparing the two a lot more complicated. 
    15 Puisque beaucoup de ces perceptions sont apparues dans le passé, ces choses ne sont plus aussi vraies avec les versions actuelles que celà n'a été. Les deux systèmes ont évolué avec des versions notables qui rendent leur comparaison beaucoup plus compliquée. 
     15Puisque beaucoup de ces perceptions sont apparues dans le passé, ces choses ne sont plus aussi vraies avec les versions 
     16actuelles que celà n'a été. Les deux systèmes ont évolué avec des versions notables qui rendent leur comparaison 
     17beaucoup plus compliquée. 
    1618 
    1719//    * MySQL 5.0 (October 2005) finally added a "strict mode" to narrow the gap in terms of data integrity and spec  
    …… 
    219221// operation is ambiguous or unsupported. 
    220222L'implémentation correcte des techniques de conception comme les formes normales repose sur la capacité de la base de  
    221 données à utiliser les Clés Étrangères pour représenter les relations entre les tables. Avec MySQL, seul InnoDB supporte 
    222 les clés étrangères. Un problème avec de leur implémentation est qu'elle est limitée et ignorera silencieusement 
    223 plusieurs syntaxes standard. Par exemple, lors de la création d'une table, même avec la prochaine version 5.1 de MySQL 
    224 "la clause CHECK est analysée mais ignorée par tous les moteurs de stockages". À l'origine de PostgreSQL, la philosophie 
    225 de conception à été de produire des erreurs ou des avertissements dans les situations similaires où une opération est 
    226 ambiguë ou non supportée. 
    227  
    228 Transactional DDL 
    229  
    230 In PostgreSQL, when you are inside a transaction almost any operation can be undone. There are some irreversible operations (like creating or destroying a database or tablespace), but normal table modifications can be backed out by issuing a ROLLBACK via its Write-Ahead Log design. That supports backing out even large changes to DDL like table creation. 
    231  
    232 MySQL doesn't support any sort of rollback when using MyISAM. With InnoDB, the server has an implicit commit that occurs even if the normal auto-commit behavior is turned off. This means that any single table alteration or similar change is immediately committed. 
    233  
    234 Experienced PostgreSQL DBA's know to take advantage of its features here to protect themselves when doing complicated work like schema upgrades. If you put all such changes into a transaction block, you can make sure they all apply atomically or not at all. This drastically lowers the possibility that the database will be corrupted by a typo or other such error in the schema change, which is particularly important when you're modifying multiple related tables where a mistake might destroy the relational key. There is no way to similar way to safely adjust multiple schema sections with MySQL. 
    235  
    236 See Transactional DDL in PostgreSQL: A Competitive Analysis for detailed examples demonstrating these differences. 
    237 Speed 
    238 Default configuration 
     223données à utiliser les Clés Étrangères pour représenter les relations entre les tables. Avec MySQL, seul InnoDB 
     224supporte les clés étrangères. Un problème avec de leur implémentation est qu'elle est limitée et ignorera 
     225silencieusement plusieurs syntaxes standard. Par exemple, lors de la création d'une table, même avec la prochaine 
     226version 5.1 de MySQL "la clause CHECK est analysée mais ignorée par tous les moteurs de stockages". La philosophie de 
     227conception à la base de PostgreSQL est de produire des erreurs ou des avertissements dans les situations similaires où 
     228une opération est ambiguë ou non supportée. 
     229 
     230// Transactional DDL 
     231DDL Transactionnel 
     232 
     233// In PostgreSQL, when you are inside a transaction almost any operation can be undone. There are some irreversible  
     234// operations (like creating or destroying a database or tablespace), but normal table modifications can be backed out  
     235// by issuing a ROLLBACK via its Write-Ahead Log design. That supports backing out even large changes to DDL like table  
     236// creation. 
     237Avec PostgreSQL, lorsque vous êtes à l'interieur d'une transaction presque toute opération peut être annulée. Il existe 
     238quelque opérations irréversibles (comme créer ou détruire une base ou un talbespace), mais les modifications classiques 
     239de table peuvent être défaites en executant un ROLLBACK grâce aux mécanismes de Write-Ahead Log. Celà s'applique 
     240aussi aux importantes modifications du DDL comme la création de tables. 
     241 
     242// MySQL doesn't support any sort of rollback when using MyISAM. With InnoDB, the server has an implicit commit that  
     243// occurs even if the normal auto-commit behavior is turned off. This means that any single table alteration or similar 
     244// change is immediately committed. 
     245MySQL ne supporte aucun type d'annulation en utilisant MyISAM. Avec InnoDB, le serveur déclenche une validation 
     246implicite même si le comportement normal d'auto-commit est désactivé. Celà signifie qu'une unique modification de 
     247table ou changement similaire est immediatement validé. 
     248 
     249// Experienced PostgreSQL DBA's know to take advantage of its features here to protect themselves when doing complicated 
     250// work like schema upgrades. If you put all such changes into a transaction block, you can make sure they all apply 
     251// atomically or not at all. This drastically lowers the possibility that the database will be corrupted by a typo or  
     252// other such error in the schema change, which is particularly important when you're modifying multiple related tables 
     253// where a mistake might destroy the relational key. There is no way to similar way to safely adjust multiple schema  
     254// sections with MySQL. 
     255Les DBA PostgreSQL expérimenté savent tirer parti de ces fonctionnalités pour s'assurer lors de travaux compliqués 
     256comme la mise à jour d'un schema. Si vous placez tous ces changements dans une transaction, vous pouvez être certain 
     257qu'elles seront toutes appliquées de façon atomique ou pas du tout. Cela abaisse drastiquement la possibilité de 
     258corruption de la base de données par une erreur de frappe ou tout autre erreur de ce genre dans les modifications du 
     259schéma, ce qui est particulièrement important lorsque vous modifiez plusieurs tables en relations où une erreur peut  
     260détruire la clé relationnelle. Il n'existe aucune méthode similaire pour ajuster sûrement plusieurs sections d'un 
     261schéma avec MySQL. 
     262 
     263// See Transactional DDL in PostgreSQL: A Competitive Analysis for detailed examples demonstrating these differences. 
     264Voir "Transactional DDL in PostgreSQL: A Competitive Analysis" pour des exemples détaillés démontrant ces différences. 
     265 
     266// Speed 
     267Rapidité 
     268 
     269// Default configuration 
     270Configuration par défaut 
     271 
    239272Historically, the initial PostgreSQL configuration was designed to support older flavors of UNIX where allocating large amounts of memory wasn't necessarily possible. The result was that its use of memory for caching results was, by default, very pessimistic. On modern systems that have lots of memory available, this severely hinders untuned PostgreSQL performance. 
    240273