Choisir Mysql ou PostGreSQL ? [Débat]

[VLDG]

Envoyé par kedare

Les sauvegardes a chaud arrivent avec la version 6.0 de Mysql

Le problème est de savoir quand va arriver la version 6

Pour la recherche full text : tu peux aussi regarder ici pour MySQL
http://www.percona.com/files//presen...008_sphinx.pdf

je sais que Firebird utilise aussi Sphinx : http://www.firebirdsql.org/index.php?op=files&id=sphinx
ou Lucene http://www.red-soft.biz/en/node/128

[kedare]

mais mysqldump c'est pas a chaud ?
j'ai l'impression que personne n'aime mysql ici ;p

[SQLpro]

J'ai surtout tendance a utiliser des base de données assez petite, genre pour des blogs et des trucs comme ca, tu conseille plutot d'utiliser quoi comme base de donnée pour ca ? mysql ? postgresql ? autre ?

Il est effectivement inutile dans ce cas particulier d'utiliser un poids lourd. Mais je préfère de loin PostGreSQL qui est du vrai libre. Avec MySQL il faut payer d'une manière ou d'une autre, soit en en code soit en licence.

j'ai migré mon blog de postgresql vers mysql pour tester un peut (facile avec django) en utilisant des tables MyISAM, et ca trace quand meme plus (surtout au niveau de la table de cache, les transactions sont inutiles ici) puis dans ce cas la je n'ai pas vraiment besoin des fonctionnalités relationnels

Il est facile d'aller vite quand on ne fait pas de transaction. Même un simple fichier texte ira plus vite dans ce cas. C'est la particularité de MySQL : aller vite lorsqu'il n'y a qu'un seule utilisateur simultané. En revanche c'est l'inverse lorsqu"il y a de nombreux utilisateurs concurrent et MySQL est connu pour se vautrer sur des transactions complexes avec forte concurrence. Cela est du essentiellement à la structure hybride de son moteur un mixte de fichier et de C/S

Code :

Je trouve aussi la commande SHOW trés simple et agréable a utiliser

La c'est vraiment le genre de connerie que je déteste et qui va à l'encontre même du free. A l'origine le free c'était pour luter contre l'hégémonie de IBM et MS avec des outils, format et commande spécifique ne respectant pas les normes et standards. Exactement ce que fait la commande SHOW qui n'existe pas. Si le langage SQL était un label de qualité et non une simple norme, alors le fait d'utiliser cette commande interdirait légalement à MySQL de spécifier le mot SQL dans son argumentaire... Et c'est pourquoi les gens qui viennent de MySQL et qui ont appris des commandes spécifique à MySQL et arrivent sur de l'Oracle du DB2, du PostGreSQL ou du SQL Server, posent des questions stupide du genre : je comprend pas je fais une requête avec GROUP_CONCACT ou SHOW et ça me renvoie une erreur dans SQL Server !!!
C'est aussi pourquoi je me bat depuis des années pour écrire des livres sur la langage SQL qui est une norme et non sur le dialecte SQL de bidule ou truc. C'est mille fois plus enrichissant et il n'y a qu'a voir les critiques de ceux qui ont lu mes ouvrages pour s'en convaincre !

Comme dit plus haut, j'ai l'impression que Mysql quitte le chemin des RDBMS classique pour aller sur son propre chemin en proposant son propre SQL

Hélas oui...

et tout ca, d'un coté ca dérange car on sais pas vraiment ce que ca vaut, mais d'un autre coté ca permet d'offrir plus de diversité

Ce qui bien entendu est totalement faux, mais le marketing de MySQL le fait croire pour faire passer la pilule. Ne pas oublier que MySQL est un produit d'entreprise, autrefois MySQL AB, et maintenant SUN... et que ces gens là ne sont pas des philanthropes....
En fait si MySQL ne fait pas ce que la norme prévoit c'est tout simplement parce qu'ils n'arrivent pas à le faire proprement.
Par exemple pendant des années MySQL était incapable de faire des transactions et des sous requêtes et le marketing, et certains internautes l'avait gobé, faisait croire que les sous requêtes c'était inutile.... !
Même chose pour GROUP_CONCAT. Comme MySQL ne sait pas faire des requêtes récursives alors on invente une fonction antirelationnelle au possible pour pallier ce manque plutôt que d'implémenter les requêtes récursives !
Les exemples dans ce domaine sont légion !

Bref, MySQL c'est le plus mauvais SGBDR C/S tant par ses bugs et ses fonctionnalités spécifiques et en plus c'est pas vraiment du libre... Mais le marketing qui à réussit à l'implanter partout, à excellemment bien fait son boulot et les jeunots qui n'ont aucune expérience en matière de SGBDR gobent cela à cent à l'heure !

mais mysqldump c'est pas a chaud ?

Non, la sauvegarde à chaud n'existe pas sous MySQL. C'est à dire que vous pouvez la faire, mais comme la sauvegarde des tables est successive, vous avez de grandes chance de retrouver la base dans un état d'incohérence à la restauration (par exemple sauvegarde de la table client puis ajout d'un client, puis ajout d'une facture à ce client puis sauvegarde de la table facture. A la restauration il y a une facture sans client et l'intégrité référentielle est violée par le SGBDR !). Alors que tous les SGBDR savent faire cela en utilisant le journal de transaction...

Quand à l'annonce de cette fonction en V 6, je n'y crois pas car les informations que j'ai eu en interne il y a quelques temps me disait strictement le contraire. Mais je vais envoyer un mail pour vérifier !

A +

[kedare]

Oki, merci pour ses informations, je vais plutot revenir sur Postgresql alors (c'est fait), et voir si je peux utiliser un systeme de cache a base de fichier et pas dans la base de donnée !

d'ailleurs pourquoi Mysql est si utilisé si c'est si naze ?

d'ailleur il me semble que postgresql n'a pas de cache de requête pour améliorer les performances, non ? C'est dommage, c'est toujours un plus.... (encore un plus pour mysql ;p)

[Jester]

S'il faut un avocat MySQL ... ;-)

MySQL n'est pas naze, il n'est juste pas parfait. Facebook par exemple utilise MySQL comme base de données principale.

De plus vous l'utilisez via de l'ORM, donc effectivement les transactions ça ne vous servira pas. La mauvaise gestion des requêtes complexes ne sera pas grave non plus.

Il est possible de faire de la sauvegarde à chaud avec InnoDB (mais pas de recherche fulltext). C'est par contre structurellement impossible avec MyIsam. Il est possible d'avoir une sauvegarde cohérente (à demi-chaud) avec MyIsam, mais en verrouillant les tables le temps de faire la sauvegarde.

[kedare]

Donc tu conseille plutot Mysql ?
En plus Postgresql est pas tip top sous windows, j'ai pas mal de problemes avec (impossible de le lancer depuis n'importe quelle compte quand on fait un package avec par exemple, puis le service ne se lance que quand il veut bien)
par contre c'est clair que le langage de procédure de Mysql est inférieur a Pl/PGSQL

J'ai l'impression que même si Mysql possède moins de features, il semble plus polyvalent que Postgresql, non ?

[Jester]

Je conseille pas forcément MySQL.

Pour certains trucs j'utilise mysql, pour d'autres postgres, tout dépend de ce que tu veux faire et de tes besoins.

Pour une utilisation à travers du mapping objet relationnel clairement je prendrais MySQL en innodb. Mais ça demandera d'installer en sus lucene pour le full text (c'est possible d'avoir un client pour lucene sous forme de moteur de stockage mysql).

Cela dit, je connais mieux MySQL et j'aime bien son fonctionnement. Il faut prendre un truc dans lequel vous êtes à l'aise c'est le plus important.

[kedare]

Envoyé par Jester

Je conseille pas forcément MySQL.
Pour une utilisation à travers du mapping objet relationnel clairement je prendrais MySQL en innodb.

Pourquoi ?

[Jester]

innodb parce qu'avec des accès par ORM ce sera très souvent sur la clé primaire et innodb stocke les données dans l'index de la clé primaire, du coup ça permet d'être rapide. De plus, innodb a un cache de données que n'a pas myisam.

[kedare]

Envoyé par Jester

innodb parce qu'avec des accès par ORM ce sera très souvent sur la clé primaire et innodb stocke les données dans l'index de la clé primaire, du coup ça permet d'être rapide. De plus, innodb a un cache de données que n'a pas myisam.

donc pour toi myisam n'est pas forcement plus performant qu'innodb ?
Django ne créer pas de Foreign Key par exemple (pourtant sous Postgresql, il les créer), donc quelle est l'intérêt d'aller sur InnoDB plutot que MyISAM ? j'ai testé et MyISAM est légèrement plus rapide

Quelle est la difference entre le cache de données, et le cache de requete que l'on trouve a la fois sur MyISAM et InnoDB ?

[Jester]

Non, comme toujours ça dépend.

[kedare]

Et pour une solution codée a la main (je prevois de refaire mon blog en php, avec des requetes codée en SQL, marre des surprises des ORM ), tu recommande aussi Mysql ?

[SQLpro]

Après avoir interroger Peter Gultzan qui est senior architecte pour MySQL, celui ci m'a bien confirmé que la sauvegarde à chaud de MySQL ne permettait pas d'assurer la consistance. Il n'est pas prévu que ceci soit réalisé dans une future version. C'est donc toujours le point noir de MySQL :
http://blogs.mysql.com/peterg/2008/0...online-backup/
Voici le texte exact de la réponse de Peter à ce sujet :
"
> quelqu'un m'a dit :
> "Les sauvegardes a chaud arrivent avec la version 6.0 de Mysql"
> Est-ce vrai ?

Nous continuons avec InnoDB Hot Backup, mysqldump, etc.
http://dev.mysql.com/doc/refman/5.0/...up-policy.html

C'est probable que quelqu'un a lu les articles sur le sujet
de "Online Backup". Par exemple ceci:
http://blogs.mysql.com/peterg/2008/0...online-backup/
La promesse, c'est sauvegarder sans beaucoup de verrouillage.
Sans garantir que tout sera "à chaud".
"

A +

[Jester]

Envoyé par kedare

Et pour une solution codée a la main (je prevois de refaire mon blog en php, avec des requetes codée en SQL, marre des surprises des ORM ), tu recommande aussi Mysql ?

Oui, mais toujours en InnoDB pour profiter des clés étrangères, de la sécurité et des sauvegardes à chaud.

[Jacknight]

Je sais que tout le monde parle de MySQL. Ce mot étant désormais connu de tous.
Cependant ne serait-il pas plus sage d'utiliser SkySQL désormais en lieu et place de MySQL ?

Depuis le rachat de Sun par Oracle et le départ d'un bon paquet de développeurs pour créer un fork de MySQL sous la dénomination SkySQL, peut être serait-il préférable de changer de nomenclature dans nos dialogues ?

SkySQL sera certainement plus rapide que MySQL pour améliorer ses fonctionnalités et tendre vers PostgreSQL.

[Jean-Marc68]

Salut Jacknight,

En effet, tu n'as sans doute pas tort, mais si tu regardes les dates des posts, tu constateras que cette discussion a été débutée en 2002 (oui oui, il y a près de 10 ans) et qu'il n'y a plus eu de post (avant le tiens) depuis 2009. Or à l'époque, on étaient encore loin de parler de SkySQL.

Ceci dit, dorénavant je pense que SkySQL sera tenu en compte, si la discussion revit.

[Oishiiii]

D'après ce que je peux lire sur leur site officiel, SkySQL n'est pas du tout un SGBDR..... c'est une boite qui créer des outils (de monitoring..) et propose des services autour de MySQL.....

[Jean-Marc68]

Merci de ta réponse Oishiiii,

Une boîte d'outils pour MySQL ? Et racheté par Microsoft. Tout cela me faite penser à des outils "accessoires" qui deviendront payant un jour. J'espère me tromper.

En fait, je ne connaissais pas SkySQL, mais pour tout avouer, j'ai décidé d'opter pour PostGRE il y a 3 ou 4 ans pour différentes raisons, entre autre parce que j'ai besoin du GIS aussi, et à l'époque PostGRE était le plus performant en GNU, surtout avec son PostGIS, pour les besoins que j'avais. Maintenant que les serveurs sont configurés, les applications développées autour de PostGRE et PostGIS, et que 5 bureaux sont formés à travailler avec ce système, je ne vais pas tout changer, d'autant plus que je suis très content de ce que j'ai.

Mais je comprends que tout se développe et que d'autres passeront devant un jour, peut-être. Là il sera temps de voir si l'investissement (changer les serveurs de système, modifier les applications, re-former du personnel, etc...) vaudra le coup.

Il est évident aussi que pour d'autres MySQL (avec ou sans SkySQL) sera plus intéressant, voire plus performants pour leurs besoins.

C'est à voir au cas par cas.