Discussion :

[VLDG]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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]

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]

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]

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.