| | 19 | // * MySQL 5.0 (October 2005) finally added a "strict mode" to narrow the gap in terms of data integrity and spec |
|---|
| | 20 | // compliance. It also added support for stored procedures, views, triggers, and cursors, all considered essential |
|---|
| | 21 | // features for some classes of database deployments. |
|---|
| | 22 | * MySQL 5.0 (Octobre 2005) a finalement ajouté un "strict mode" pour réduire l'écart en terme d'intégrité des |
|---|
| | 23 | données et de conformité aux specs. Le support des procédures stockées, vues, déclencheurs et curseurs, tous |
|---|
| | 24 | considérés comme des fonctionnalités essentielles dans plusieurs cas de déploiement de base de données, ont |
|---|
| | 25 | aussi été ajoutés. |
|---|
| | 26 | // * PostgreSQL 8.1 (November 2005) featured major performance improvements, particularly in scalability. Focusing |
|---|
| | 27 | // on improving performance has been central to all the 8.X releases up to the current 8.2. |
|---|
| | 28 | * PostgreSQL 8.1 (Novembre 2005) apporte d'importantes améliorations de performance, particulièrement en terme |
|---|
| | 29 | d'évolutivité. L'attention a principalement été portée sur l'amélioration des performances pour toutes les |
|---|
| | 30 | versions 8.X et jusqu'à l'actuelle 8.2. |
|---|
| 17 | | * 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. |
|---|
| 18 | | * PostgreSQL 8.1 (November 2005) featured major performance improvements, particularly in scalability. Focusing on improving performance has been central to all the 8.X releases up to the current 8.2. |
|---|
| | 32 | // As innovation on these databases has progressed, each development community has actively made changes to address |
|---|
| | 33 | // their respective sets of perceived disadvantages. The result that it has gotten more difficult to objectively |
|---|
| | 34 | // determine which database is likely to be better suited for a given application. This document aims to clarify what |
|---|
| | 35 | // situations PostgreSQL would be more appropriate for than MySQL, attempting to fairly compare the current production |
|---|
| | 36 | // versions of each and discuss their strengths and weaknesses. The main areas covered here are the fundamental data |
|---|
| | 37 | // integrity and speed issues of the core database software. Since it's often the case that you can trade-off |
|---|
| | 38 | // performance against reliability, both these topics need to be considered together in order to get an accurate view |
|---|
| | 39 | // of the landscape. |
|---|
| | 40 | Alors que l'innovation sur ces deux bases a progressé, chacune des communautés de développement ont travaillé |
|---|
| | 41 | activement à réduire leur liste de désavantages perçus. Le résultat est qu'il est devenu plus difficile de déterminer |
|---|
| | 42 | objectivement quel base de données est susceptible de convenir à une application donnée. Ce document vise à clarifier |
|---|
| | 43 | dans quelles situations PostgreSQL est plus approprié que MySQL, en essayant de comparer équitablement les versions de |
|---|
| | 44 | production courante de chacune et d'en discuter les forces et faiblesses. Les domaines principaux étudiés ici |
|---|
| | 45 | concernent les questions fondamentales de l'intégrité des données et la vitesse du noyau logiciel de la base de donnée. |
|---|
| | 46 | Puisqu'il est souvent question de faire un choix entre la performance ou la fiabilité, ces deux sujets doivent être |
|---|
| | 47 | considérés ensemble afin d'avoir une vision précise de l'ensemble. |
|---|
| 20 | | As innovation on these databases has progressed, each development community has actively made changes to address their respective sets of perceived disadvantages. The result that it has gotten more difficult to objectively determine which database is likely to be better suited for a given application. This document aims to clarify what situations PostgreSQL would be more appropriate for than MySQL, attempting to fairly compare the current production versions of each and discuss their strengths and weaknesses. The main areas covered here are the fundamental data integrity and speed issues of the core database software. Since it's often the case that you can trade-off performance against reliability, both these topics need to be considered together in order to get an accurate view of the landscape. |
|---|
| 21 | | |
|---|
| 22 | | The position of this paper is that when the two are compared using the high level of data integrity demanded by a serious transactional database application, the current generation PostgreSQL performs similarly or better than MySQL (particularly under heavy user loads and with complex queries), while retaining its lead in the areas of SQL standards compliance and a rich feature set. It is also hoped that by exploring the differences between the two systems, you might come to appreciate how the fundamental approach of the PostgreSQL design team pervasively prioritizes reliable and predictable behavior. Similar portions of the MySQL implementation have some seams resulting from how features like transactional support and strict mode were added onto the software well into its design lifecycle rather than being integral from the start. |
|---|
| 23 | | Compared Versions, Feature Sets, and Focus |
|---|
| | 49 | // The position of this paper is that when the two are compared using the high level of data integrity demanded by a |
|---|
| | 50 | // serious transactional database application, the current generation PostgreSQL performs similarly or better than |
|---|
| | 51 | // MySQL (particularly under heavy user loads and with complex queries), while retaining its lead in the areas of SQL |
|---|
| | 52 | // standards compliance and a rich feature set. It is also hoped that by exploring the differences between the two |
|---|
| | 53 | // systems, you might come to appreciate how the fundamental approach of the PostgreSQL design team pervasively |
|---|
| | 54 | // prioritizes reliable and predictable behavior. Similar portions of the MySQL implementation have some seams |
|---|
| | 55 | // resulting from how features like transactional support and strict mode were added onto the software well into its |
|---|
| | 56 | // design lifecycle rather than being integral from the start. |
|---|
| | 57 | // Compared Versions, Feature Sets, and Focus |
|---|
