Ce petit bijoux fonctionne en standalone mais aussi avec MySQL auquel il apporte le support des transactions et aussi le verrouillage au niveau ligne et non pas table.
InnoDB semble très prometteur.
Note du modérateur : InnoDb est directement présent dans les nouvelles versions de MySQL.
maintenant que les benchs de rapidité sont faits, il faudrait aussi en faire pour la stabilité - qui est quand même l'un des principaux avantages de PostgreSQL par rapport à MySQL, bien qu'il soit plus lent.
(outre le fait que MySQL n'est pas relationnel, que MySQL ne sait pas gérer les triggers ni les procédures stockées, etc...)
t'es pas un peu dur de la feuille toi ?
Non ?
Parce que la réponse à ta question est déjà dans le message précédent, la notion de base relationnelle est suffisamment précise et codifiée pour savoir à quoi s'en tenir.
Si t'as jamais entendu parler de dépendances fonctionnelles, de tuples, de formes normales et de toutes les joyeusetés de la théorie des bases de données, c'est même pas la peine d'insister ...
sinon, tu peux te documenter entre autres, sur l'ouvrage de G. Gardarin "Base de Données objet et relationnel" très didactique sur le sujet
Innobase adds transactions, rollback, commit, row level locking, and an Oracle-style consistent non-locking read to MySQL, the popular open-source
database. The combination MySQL/Innobase is probably the world's fastest disk-based relational transactional database.
Les perfs ont l'air tres prometteurs, en plus il y a le support des transactions: bref ca a l'air excellent!
Maintenant je veux les critiques! Quels sont les points faibles?
S'il y a un utilisateur, il pourrait nous donner son avis? La fiabilite, les limites etc..
J'aime bcp MySql, j'adore meme, mais le gros probleme de MySql reste quand meme l'absence total de SP, de triggers, et surtout, l'integrite referenciel. Tout ca allege non seulement le dev, mais aussi augmente significativement les perfs.
Faire un select sur un million de records, faire des traitements dessus et les renvoyer au serveur bouffe enormement de temps, alors que les faire directement sur le serveur avec une procedure est bien plus efficace. PostgreSQL et Interbase par example sont deux RDBMS qui permettent ca et c'est un bonheur que de developper dessus.
MySQL pour un serveur WEB, c'est parfait, on a rarement besoin de tout ca pour un serveur WEB, mais pour tout le reste ...
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 !!!
# Benchs
Posté par Yann Hirou . Évalué à 1.
(outre le fait que MySQL n'est pas relationnel, que MySQL ne sait pas gérer les triggers ni les procédures stockées, etc...)
[^] # Re: Benchs
Posté par Alain Tésio . Évalué à 1.
par un organisme impartial !
[^] # Re: Benchs
Posté par Anonyme . Évalué à 0.
[^] # Re: Benchs
Posté par Anonyme . Évalué à 0.
[^] # Re: Benchs
Posté par Anonyme . Évalué à 0.
[^] # Pas SQL ANSI
Posté par Anonyme . Évalué à 0.
Par exemple, par de support des SELECT imbriqués, pas de support correct des FOREIGN KEYS, pas de triggers...
Que ceux qui mettent ça en doute aillent plutôt relire leur cours de BDD.
Foxy (pas authentifié)
[^] # Re: Pas SQL ANSI
Posté par Anonyme . Évalué à 0.
et toi ton esprit critique.
en quoi le non support des SELECT imbriqués fairait de MySQL un SGBD et non un SGBDR ?
j'espere te lire a nouveau rapidement
[^] # Re: Pas SQL ANSI
Posté par Anonyme . Évalué à -1.
Non ?
Parce que la réponse à ta question est déjà dans le message précédent, la notion de base relationnelle est suffisamment précise et codifiée pour savoir à quoi s'en tenir.
Si t'as jamais entendu parler de dépendances fonctionnelles, de tuples, de formes normales et de toutes les joyeusetés de la théorie des bases de données, c'est même pas la peine d'insister ...
sinon, tu peux te documenter entre autres, sur l'ouvrage de G. Gardarin "Base de Données objet et relationnel" très didactique sur le sujet
[^] # Re: Pas SQL ANSI
Posté par gle . Évalué à 1.
# Complément d'info sur Mysql/Innodb
Posté par Yann Hirou . Évalué à 1.
database. The combination MySQL/Innobase is probably the world's fastest disk-based relational transactional database.
# Quels sont les points faibles?
Posté par reno . Évalué à 1.
Maintenant je veux les critiques! Quels sont les points faibles?
S'il y a un utilisateur, il pourrait nous donner son avis? La fiabilite, les limites etc..
[^] # Re: Quels sont les points faibles?
Posté par Anonyme . Évalué à 0.
J'aime bcp MySql, j'adore meme, mais le gros probleme de MySql reste quand meme l'absence total de SP, de triggers, et surtout, l'integrite referenciel. Tout ca allege non seulement le dev, mais aussi augmente significativement les perfs.
Faire un select sur un million de records, faire des traitements dessus et les renvoyer au serveur bouffe enormement de temps, alors que les faire directement sur le serveur avec une procedure est bien plus efficace. PostgreSQL et Interbase par example sont deux RDBMS qui permettent ca et c'est un bonheur que de developper dessus.
MySQL pour un serveur WEB, c'est parfait, on a rarement besoin de tout ca pour un serveur WEB, mais pour tout le reste ...
enfin, moi, ce que j'en dis ... :)
[^] # TROLL : linuxfr pro mysql
Posté par Anonyme . É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...
# Interbase : l'alternative opensource ...
Posté par Anonyme . Évalué à 0.
Et surtout qu'il supporte integralement SQL92 et presque la totalité de SQL99,
Cela inclut: Transactions, procedures stockées, vue, etc ...
Bref, une vrai base, gratos et avec des outils gratos (drivers JDBC/Java, outils d'admin, outils de migration, de recovery, etc ...)
J'aimerais bien voir un bench de perfs : MySQL vs Interbase ;-)
A+
3hck.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.