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
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 +
Partager