Re: Convaincre mon boss / client : MySQL contre PostgreSQL

kaliderus <kaliderus(at)gmail(dot)com> writes:
> On va dire que j'ai 1 minute pour convaincre mon chef (ou mon client)
> que PostgreSQL c'est bien (en tout cas mieux que l'autre base).
>
> Quels seraient selon vous les arguments imparables à mettre en avant ?

Pour moi les bonnes raisons d'utiliser PostgreSQL sont, dans l'ordre ou
presque :

- PostgreSQL respecte avant tout les données qui lui sont confiées

ACID, Durabilité, backups à chaud, types de données, contraintes
d'intégrité, etc

- PostgreSQL permet donc d'implémenter facilement un service d'accès
aux données commun à plusieurs applications (production, web,
dashboard, compta, reporting, etc) en gérant les accès concurrents
et la validité des données, quand MySQL laisse *TOUT* cela à la
charge des équipes de développement ;

- Un rythme d'innovation spectaculaire ;

- Souplesse d'architecture inégalée, adaptation aisée à tous les
besoins : c'est un système vraiment versatile.

Si tu as besoin d'aide afin d'argumenter la valeur ajoutée et le retour
sur investissement d'un passage à PostgreSQL, n'hésite pas à me
contacter en privé.

Si tu as besoin d'aide afin de réaliser la migration, de même. Tu peux
déjà regarder pgloader version 3 pour t'aider, mon billet le plus récent
à ce sujet est disponible sur mon site, et l'outil a déjà bien évolué
depuis :

http://tapoueh.org/blog/2013/08/08-MySQL-to-PostgreSQL
http://www.postgresql.eu/events/sessions/pgconfeu2013/session/464-migrating-from-mysql-to-postgresql/

Sinon, j'ai lu récemment un mail que j'ai bien aimé, même si la liste me
semble loin d'être exhaustive (je ne vois pas, entre autres et presque
au hasard, LISTEN/NOTIFY ou bien la réplication synchrone ou asychrone
réglable *par transaction*, ni même le protocole COPY pour du streaming
de données, ou bien les algorithmes avancés de jointures) :

Things that MySQL (and I believe MariaDB as well) still doesn't have (and PostgreSQL has):

deferrable constraints
check constraints
Non transactional FK evaluation (http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html)
--> constraints are always checked row-by-row, not on statement level
recursive queries
table functions
common table expressions
windowing functions
function based index
partial index
transactional DDL
full text search on transactional tables (changed with 5.6)
GIS features on transactional tables
MINUS or INTERSECT operator
stemming in full text search
user defined aggregate functions
domains or user defined types
statement level triggers
conditional triggers
Triggers are not fired from cascading deletes
sequences
EXPLAIN for non-select statements or prepared statements (seems to have changed with MySQL 5.6)
No descending indexes
Sub-Selects and derived tables are still 2nd class "citizens"
--> cannot use table being updated in a subselect
--> cannot use derived tables in views
rename columns that are part of a foreign key constraint
call stored procedures in triggers


Things that Postgres doesn't have that MySQL/MariaDB has

WITH CHECK option for views
declarative partitioning

Si ton chef (ou ton client) apprécie d'être remis en question, tu peux
lui dire qu'il n'existe pas de bonne raison de préférer MySQL en 2013.

Cela peut faire sourire, mais cela fait déjà quelques années que je n'ai
rencontré un cas d'usage où MySQL / MariaDB / Perconna serait le bon
choix, à condition d'analyzer un peu sérieusement les besoins.

Évidemment PostgreSQL parfois n'est pas le bon choix non plus, et il
faut savoir reconnaître ces cas là et utiliser le bon outil…

En te souhaitant du succès dans ta démarche,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)