Perso, c'est l'un des gros soucis que je trouve à MySQL, les fonctionnalités à moitié implémentées avec des PS dans la doc et le manque de cohérence global.
> À la rigueur, tu aurais été pertinent en disant que MySQL ne supporte pas les triggers ou les procédures stockées mais MySQL 5.x le permet
Parlons de rigueur justement, je cite "Currently, triggers are not activated by cascaded foreign key actions." (présent dans le lien donné plus haut). La version 5.0 qui est donc la dernière version stable ne permet pas d'utiliser des triggers en étant certain de l'intégrité de la base.
C'est à mon avis un autre gros problème : faire de la publicité sur des fonctionnalités qui sont implémentées partiellement et remettent en cause la véracité des données.
MySQL correspond tout à fait à pas mal de cas d'usage. Mais il ne faut pas non plus pousser le bouchon...
> et la quasi-totalité des applications Web populaires utilisant PostreSql n'en font même pas usage
Tu parles de celles qui ont été développées avec une couche d'abstraction, qui sont compatibles avec MySQL en MyISAM et qui donc doivent tenir compte de ses limitations ?
En tous les cas, je n'ai pas développé une application web qui utilise PostgreSQL sans avoir recours à des triggers.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. Évalué à 4.
http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.h(...)
on est tout de suite moins partant...
Perso, c'est l'un des gros soucis que je trouve à MySQL, les fonctionnalités à moitié implémentées avec des PS dans la doc et le manque de cohérence global.
Certains de ces problèmes (notamment la problématique du COUNT(*)) transparaissent dans cet article :
http://feedlounge.com/blog/2005/11/20/switched-to-postgresql(...)
> À la rigueur, tu aurais été pertinent en disant que MySQL ne supporte pas les triggers ou les procédures stockées mais MySQL 5.x le permet
Parlons de rigueur justement, je cite "Currently, triggers are not activated by cascaded foreign key actions." (présent dans le lien donné plus haut). La version 5.0 qui est donc la dernière version stable ne permet pas d'utiliser des triggers en étant certain de l'intégrité de la base.
C'est à mon avis un autre gros problème : faire de la publicité sur des fonctionnalités qui sont implémentées partiellement et remettent en cause la véracité des données.
MySQL correspond tout à fait à pas mal de cas d'usage. Mais il ne faut pas non plus pousser le bouchon...
> et la quasi-totalité des applications Web populaires utilisant PostreSql n'en font même pas usage
Tu parles de celles qui ont été développées avec une couche d'abstraction, qui sont compatibles avec MySQL en MyISAM et qui donc doivent tenir compte de ses limitations ?
En tous les cas, je n'ai pas développé une application web qui utilise PostgreSQL sans avoir recours à des triggers.