J'ai utilisé Postgresql pendant un temps et j'avais beaucoup apprécié les fonctionnalités et la rigueur du système.
Depuis, je suis revenu sur MySQL pour des raisons indépendantes de ma volonté. MySQL me donne l'impression d'un soft un peu 'sale' et pas terminé. La version 5 est plus rigoureuse que la série des 4.1.x, mais il y a toujours cette impression d'inachevé. Je pense notamment au (non) support des transactions imbriquées.
Combiné avec le côté 'pas propre' de la chose - ie. ouvrir une transaction dans une transaction provoque un commit de la transaction en cours et l'ouverture d'une nouvelle transaction sans aucun message d'erreur - c'est _impossible_ de faire des procédures stockées transactionnées. Ou alors on prend le risque de commiter la transaction en cours si l'utilisateur en avait ouvert une avant d'appeler la procédure. La conclusion, pour moi, c'est que les nouvelles fonctionnalités (procédures stockées, triggers, ...) de cette version 5 sont franchements limitées.
Bref, il reste encore du boulot à faire sur MySQL, mais il faut reconnaître une chose : le système de réplication Master -> (n) Slave est très pratique et n'a pas d'équivalent sur Postgresql. C'est très dommage, d'autant plus que Postgresql intègre un log des écritures dans la base (comme MySQL) et qu'il suffirait de pas grand chose pour rejouer ce log en temps réel sur un ou plusieurs replicats, à la manière de MySQL.
Alors OK, il y'a Slony qui permet de répliquer des bases Postgresql, je trouve le système un peu archaïque, peu sur et assez lourd (notamment si la structure de la base change de temps à autre).
# Système de réplication poussif
Posté par BiBite . En réponse au journal Introduction à PostgreSQL. Évalué à 1.
Depuis, je suis revenu sur MySQL pour des raisons indépendantes de ma volonté. MySQL me donne l'impression d'un soft un peu 'sale' et pas terminé. La version 5 est plus rigoureuse que la série des 4.1.x, mais il y a toujours cette impression d'inachevé. Je pense notamment au (non) support des transactions imbriquées.
Combiné avec le côté 'pas propre' de la chose - ie. ouvrir une transaction dans une transaction provoque un commit de la transaction en cours et l'ouverture d'une nouvelle transaction sans aucun message d'erreur - c'est _impossible_ de faire des procédures stockées transactionnées. Ou alors on prend le risque de commiter la transaction en cours si l'utilisateur en avait ouvert une avant d'appeler la procédure. La conclusion, pour moi, c'est que les nouvelles fonctionnalités (procédures stockées, triggers, ...) de cette version 5 sont franchements limitées.
Bref, il reste encore du boulot à faire sur MySQL, mais il faut reconnaître une chose : le système de réplication Master -> (n) Slave est très pratique et n'a pas d'équivalent sur Postgresql. C'est très dommage, d'autant plus que Postgresql intègre un log des écritures dans la base (comme MySQL) et qu'il suffirait de pas grand chose pour rejouer ce log en temps réel sur un ou plusieurs replicats, à la manière de MySQL.
Alors OK, il y'a Slony qui permet de répliquer des bases Postgresql, je trouve le système un peu archaïque, peu sur et assez lourd (notamment si la structure de la base change de temps à autre).