
Je vois beaucoup de gens vanter le systeme de moteurs de stockage que l’on trouve dans Mysql, soit disant avantageux, et bien NON, désolé de vous décevoir, ce systeme n’a absolument aucune avantage, pourquoi ? Exemple:
Eh oui, on vois souvent comparer les features de tout les moteurs de stockages confondus de Mysql avec d’autre base de donnée, seulement dans Mysql vous ne pouvez pas tout utiliser… Vous devez sacrifier certains bénéfices au profits d’autres.
Exemple de commentaire d’une personne switchant sous Mysql:
One advantage you’ll have with MySQL over SQL Server is in the area of MySQL storage engines. I can’t tell you how many customers have told me they use MySQL over other databases like SQL Server because of its pluggable storage engine architecture. When I first began looking at storage engines, I was a bit skeptical, but not anymore. As a DBA, what I like is the flexibility storage engines offer. In one database, I can have tables that are transactional or not, main memory or not, compress data or not, and on. And each storage engine supplies performance and usage advantages over using just traditional tables like you find in SQL Server.
In addition, I like that not only do we at MySQL/Sun develop storage engines, but other vendors do as well, which helps us innovate faster. We have third-party vendors that have created column-oriented data warehouse engines, OLAP engines, transactional engines, and more. Using and switching between storage engines is very easy as well. In the end, what storage engines give you over SQL Server is more choice, opportunities for higher performance, and better adaptability for your applications.
Source
Et bien voila mes réponses :
“I can have tables that are transactional or not”
Désolé mon monsieur, mais dans une base de données, l’intégrité des données est la priorité absolu, donc faire une base de données sans transaction c’est une hérésie…
“main memory or not”
Pour ca il y a des outils spécialisé et bien plus rapide que Mysql, comme Memcached par exemple, une base de donnée ca a pour but de stocker les données de façon persistante.
“compress data or not”
Comme a peut prêt n’importe quel système de bases de données un minimum évolué, Ah oui mais il a oublié de préciser que les bases de données compressé sont soit en lecture seul (MyISAM COMPRESSED), ou très limité (ARCHIVE, SELECT et INSERT seulement, sans indexes), Mince c’est rageant quand on vois a coté que Postgresql compresse très bien les données en gardant toutes ses fonctionnalités (ALTER TABLE…. SET STORAGE MAIN|EXTENDED) !
“switching between storage engines is very easy as well.”
Pour une base de donnée qui fais 10Mo ou moins, OK, mais quand vous avez une base de données de plus de 100Mo, laissez tombez la conversion via ALTER TABLE, vous allez vous taper un joli timeout, vous avez plus qu’a dump toute la table, modifier le .sql et tout re-importer.. :)
Rajoutez a ca le fait que chaque moteur de stockage a son propre système de backup, ca devient vite l’enfer de faire des sauvegardes de sa base de données…..
Bref vous avez deux choix :
Je sais pas vous, mais je trouve la deuxième solution bien plus séduisante. :)
Dans les autres défaut de Mysql, on retrouve le support SQL assez minable de base (sans sql_mode=AINSI), par exemple le double-quote sert a entourer les strings alors que la norme SQL spécifie qu’il est censé délimiter les identifiant (noms de table, colonnes, etc), dans mysql on doit utiliser un quote que presque personne n’utilise, le ` !
Donc si vous tentez une requête respectant le standard SQL, et bien ca ne marchera pas, c’est simple, vous aurez un super messages d’erreur Mysql pas du tout explicite (comme tout les autres bizarrement…)
Donc en gros, NON le système de stockage modulaire de Mysql n’est PAS un avantage !
2 commentaires
Personne n'utilise le fulltext search de MySQL : c'est lent. Il faut utiliser Sphinx qui fonctionne avec InnoDB.
La licence GPL de MySQL est aussi une très mauvaise chose !
Mieux vaut utiliser PostgreSQL ou Firebird
Oui j'avais fais quelques testes et sur des volumes de données qui commencent a grossir, c'est lent... Très lent,
mais c'est quasiment la même chose sur Postgresql et tsearch, donc je pense que dans les deux cas il faut toute facon se pencher sur un "vrais" outils de recherche fulltext plutot que d'utiliser celui fournis dans les bases de données.