J'ai posté deux fois une news pour indiquer que postgresql V7.1 était sorti.
N'a pas été publié. OK c'est peut être la ligne éditorial : on cause peu des bases de donnée.
Et bien non.
MySQL est bien OK. Postgresql est bien OK. Les objectifs ne sont pas les mêmes.
Pour les benchmarks, je me pisse dessus lorsqu'ils utilisent le minimum de caractéristiques.
Sans :
- accès concurrent : hyper important pour la tenue en charge et une base de donnée rapide c'est particulairement bien pour la tenue en charge ! S'il n'y a qu'une personne qui fouille la base de donnée, il y a peu de problème de performance !
- controle d'intégrité (référenciel, trigger, procédure, etc...) : hyper important car locker les tables (oops, plus d'accès concurrent!), faire les requêtes qui vont bien pour controler que tout est OK (via le client et serveur), puis faire de boulot (insertion d'un enregistrement par exemple), libérer les tables, et bien tout çà est obsolument horrible pour les benchmarks.
De plus faire un appli web qui controle tout avec php (lock, test, insertion) puis tout recommencer pour faire un interface avec MS access c'est hyper mauvais pour les bugs et les benchmarks du développeur.
Vivement MySQL en assembleur avec support complet de MMX !!!
[^] # TROLL : linuxfr pro mysql
Posté par Anonyme . En réponse à la dépêche Plus rapide que MySQL !. Évalué à 0.
N'a pas été publié. OK c'est peut être la ligne éditorial : on cause peu des bases de donnée.
Et bien non.
MySQL est bien OK. Postgresql est bien OK. Les objectifs ne sont pas les mêmes.
Pour les benchmarks, je me pisse dessus lorsqu'ils utilisent le minimum de caractéristiques.
Sans :
- accès concurrent : hyper important pour la tenue en charge et une base de donnée rapide c'est particulairement bien pour la tenue en charge ! S'il n'y a qu'une personne qui fouille la base de donnée, il y a peu de problème de performance !
- controle d'intégrité (référenciel, trigger, procédure, etc...) : hyper important car locker les tables (oops, plus d'accès concurrent!), faire les requêtes qui vont bien pour controler que tout est OK (via le client et serveur), puis faire de boulot (insertion d'un enregistrement par exemple), libérer les tables, et bien tout çà est obsolument horrible pour les benchmarks.
De plus faire un appli web qui controle tout avec php (lock, test, insertion) puis tout recommencer pour faire un interface avec MS access c'est hyper mauvais pour les bugs et les benchmarks du développeur.
Vivement MySQL en assembleur avec support complet de MMX !!!
PS : PostgreSQL V7.1.1 est sortie...