J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Merci -- Kevin
Le 16-11-2010, Sebastien Lardiere <sebastien.lardiere@free.fr> a écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Merci -- Kevin
Sebastien Lardiere
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere a écrit :
j'ai une table mySQL qui a différents indexs. Est il possible de supprimer ces indexs sans toucher à la table? Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ), dans un OS décent, une table pas trop grosse régulièrement lue, et pas trop mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment parce qu'il est capable de trouvé tres vite des enregistrements, alors que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index ( fct des requêtes), et ça marche.
-- Sébastien
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere <sebastien.lardiere@free.fr> a écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ), dans
un OS décent, une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ), dans un OS décent, une table pas trop grosse régulièrement lue, et pas trop mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment parce qu'il est capable de trouvé tres vite des enregistrements, alors que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index ( fct des requêtes), et ça marche.
-- Sébastien
SQLpro
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere a écrit :
j'ai une table mySQL qui a différents indexs. Est il possible de supprimer ces indexs sans toucher à la table? Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
dans un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment parce qu'il est capable de trouvé tres vite des enregistrements, alors que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index ( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la table...
Donc de deux chose l'une : 1) soit on a indexé n'importe quoi 2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici : http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere<sebastien.lardiere@free.fr> a écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
dans
un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la
table...
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
A +
--
Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
dans un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment parce qu'il est capable de trouvé tres vite des enregistrements, alors que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index ( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la table...
Donc de deux chose l'une : 1) soit on a indexé n'importe quoi 2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici : http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
A +
-- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts & Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
helios
SQLpro a écrit :
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere a écrit :
j'ai une table mySQL qui a différents indexs. Est il possible de supprimer ces indexs sans toucher à la table? Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
MySQL n'achete pas des complesance comme microsoft voir certain arborant une certif microsoft qui n'est ni plus ni moins qu un pot de vin pour critiquer les autres
et certain ne sachant pas modelisé une date dans un SGBD s'autoproclame expert SGBD et le droit de juger MySQL
dans un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment parce qu'il est capable de trouvé tres vite des enregistrements, alors que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index ( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la table...
"polus" ?????
Donc de deux chose l'une : 1) soit on a indexé n'importe quoi 2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un SGBDR par notre interlocuteurs.
Tout interlocuteur qui n'encense pas dieu Brouard n'est qu'un ignorant
Quand à MySQL, ce que j'en pense a été résumé ici : http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
et ce qu'il faut penser de l'auteur est resumé dans le fait qu'il ne sait pas modelisé une date dans un SGBD
A +
SQLpro a écrit :
bonjour,
Le 16/11/2010 13:54, Sebastien Lardiere a écrit :
On 11/16/2010 12:29 PM, Kevin Denis wrote:
Le 16-11-2010, Sebastien Lardiere<sebastien.lardiere@free.fr> a
écrit :
j'ai une table mySQL qui a différents indexs.
Est il possible de supprimer ces indexs sans toucher à la table?
Comment?
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de
la table. Comme elle est petite (- de 100Mo), je me demande s'il ne
vaut pas mieux que je la colle en RAM et que je supprime tous les
indexs.
Avez vous une idée de l'impact sur les performances de la base?
-Il vaut mieux garder les index dans tous les cas
-Dans le cas d'une petite base sur un support rapide (RAM) alors
on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
MySQL n'achete pas des complesance comme microsoft voir certain arborant
une certif microsoft qui n'est ni plus ni moins qu un pot de vin pour
critiquer les autres
et certain ne sachant pas modelisé une date dans un SGBD s'autoproclame
expert SGBD et le droit de juger MySQL
dans
un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop
mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du
SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment
parce qu'il est capable de trouvé tres vite des enregistrements, alors
que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index
( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la
table...
"polus" ?????
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Tout interlocuteur qui n'encense pas dieu Brouard n'est qu'un ignorant
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
et ce qu'il faut penser de l'auteur est resumé dans le fait qu'il ne
sait pas modelisé une date dans un SGBD
J'ai une taille d'index qui peut être 4 à 5x supérieure à la taille de la table. Comme elle est petite (- de 100Mo), je me demande s'il ne vaut pas mieux que je la colle en RAM et que je supprime tous les indexs. Avez vous une idée de l'impact sur les performances de la base? -Il vaut mieux garder les index dans tous les cas -Dans le cas d'une petite base sur un support rapide (RAM) alors on peut jeter les index sans problèmes.
Dans un SGBD digne de ce nom ( disons qu'innodb s'en rapproche ),
MySQSL un SGBDR ??? Ah bon... ;-)
MySQL n'achete pas des complesance comme microsoft voir certain arborant une certif microsoft qui n'est ni plus ni moins qu un pot de vin pour critiquer les autres
et certain ne sachant pas modelisé une date dans un SGBD s'autoproclame expert SGBD et le droit de juger MySQL
dans un OS décent,
ça existe ???
une table pas trop grosse régulièrement lue, et pas trop mise à jour sera de fait en RAM ( cache disque, ou buffer partagé du SGBD ).
Ensuite, selon les requêtes, un index peut être meilleur, notamment parce qu'il est capable de trouvé tres vite des enregistrements, alors que sans index, un scan complet de la table est requis.
Donc, suffisamment de RAM, un bon paramétrage du SGBD et les bons index ( fct des requêtes), et ça marche.
La seule chose qui m'interpelle, c'est un index bien polus gros que la table...
"polus" ?????
Donc de deux chose l'une : 1) soit on a indexé n'importe quoi 2) soit on n'a pas géré la maintenance des index (fragmentation.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un SGBDR par notre interlocuteurs.
Tout interlocuteur qui n'encense pas dieu Brouard n'est qu'un ignorant
Quand à MySQL, ce que j'en pense a été résumé ici : http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
et ce qu'il faut penser de l'auteur est resumé dans le fait qu'il ne sait pas modelisé une date dans un SGBD
A +
Sebastien Lardiere
On 11/16/2010 09:57 PM, SQLpro wrote:
Donc de deux chose l'une : 1) soit on a indexé n'importe quoi 2) soit on n'a pas géré la maintenance des index (fragmentation.
De toute façons, à part REINDEX, dans MySQL, il n'existe pas grand chose.
Et je pense qu'il parlait de l'ensemble des index qui est plus gros que la table. Ce qui est possible, même si ça n'est pas une chose à faire, amha.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici : http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au contraire.
Et puis, à bien des points de vues, l'utilisation et l'administration d'un systeme est très relatif. Par exemple, dans mon cas ( DBA PostgreSQL sous Linux), on vient de me coller dans les pattes un MS-SQL Server, et bien, c'est juste une *HORREUR* à utiliser et à administrer ; Mais ce n'est qu'une question de point de vue.
-- Sébastien
On 11/16/2010 09:57 PM, SQLpro wrote:
Donc de deux chose l'une :
1) soit on a indexé n'importe quoi
2) soit on n'a pas géré la maintenance des index (fragmentation.
De toute façons, à part REINDEX, dans MySQL, il n'existe pas grand chose.
Et je pense qu'il parlait de l'ensemble des index qui est plus gros que
la table. Ce qui est possible, même si ça n'est pas une chose à faire,
amha.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un
SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici :
http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne
voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au
contraire.
Et puis, à bien des points de vues, l'utilisation et l'administration
d'un systeme est très relatif. Par exemple, dans mon cas ( DBA
PostgreSQL sous Linux), on vient de me coller dans les pattes un MS-SQL
Server, et bien, c'est juste une *HORREUR* à utiliser et à administrer ;
Mais ce n'est qu'une question de point de vue.
Donc de deux chose l'une : 1) soit on a indexé n'importe quoi 2) soit on n'a pas géré la maintenance des index (fragmentation.
De toute façons, à part REINDEX, dans MySQL, il n'existe pas grand chose.
Et je pense qu'il parlait de l'ensemble des index qui est plus gros que la table. Ce qui est possible, même si ça n'est pas une chose à faire, amha.
Dans tous les cas, il y a visiblement ignorance totale de ce qu'est un SGBDR par notre interlocuteurs.
Quand à MySQL, ce que j'en pense a été résumé ici : http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au contraire.
Et puis, à bien des points de vues, l'utilisation et l'administration d'un systeme est très relatif. Par exemple, dans mon cas ( DBA PostgreSQL sous Linux), on vient de me coller dans les pattes un MS-SQL Server, et bien, c'est juste une *HORREUR* à utiliser et à administrer ; Mais ce n'est qu'une question de point de vue.
-- Sébastien
Sebastien Lardiere
On 11/17/2010 10:24 AM, Sebastien Lardiere wrote:
> Quand à MySQL, ce que j'en pense a été résumé ici : > http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au contraire.
Bon, j'ai lu un peu plus loin, et ce que vous dites est surement vrai ( je ne vais pas tout vérifier ), le seul point qui ne va pas, c'est que tout ce que vous dites, les utilisateurs de MySQL s'en contre-foutent, dans les grandes largeurs, vous n'imaginez même pas. Certains ne savent même pas ce qu'est une clé primaire ...
Et même des utilisateurs de SQL-Server ou Oracle ou DB2 ( que j'ai migré à PostgreSQL ) n'utilisait pas 10% des fonctionnalités que vous décrivez.
Je n'ai jamais vu de CTE chez mes clients, par exemple, ou d'index sur une expression ... Bon évidemment, j'intervenais chez ceux qui avaient des problèmes avec leur SGBD, pas chez ceux qui maitrisaient.
C'est dommage, j'en suis bien convaincu. Amha, vous perdez du temps à écrire des articles comme celui-là ; Ceux qui "choisissent" MySQL n'en ont rien à faire ...
-- Sébastien
On 11/17/2010 10:24 AM, Sebastien Lardiere wrote:
> Quand à MySQL, ce que j'en pense a été résumé ici :
> http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne
voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au
contraire.
Bon, j'ai lu un peu plus loin, et ce que vous dites est surement vrai (
je ne vais pas tout vérifier ), le seul point qui ne va pas, c'est que
tout ce que vous dites, les utilisateurs de MySQL s'en contre-foutent,
dans les grandes largeurs, vous n'imaginez même pas. Certains ne savent
même pas ce qu'est une clé primaire ...
Et même des utilisateurs de SQL-Server ou Oracle ou DB2 ( que j'ai migré
à PostgreSQL ) n'utilisait pas 10% des fonctionnalités que vous décrivez.
Je n'ai jamais vu de CTE chez mes clients, par exemple, ou d'index sur
une expression ... Bon évidemment, j'intervenais chez ceux qui avaient
des problèmes avec leur SGBD, pas chez ceux qui maitrisaient.
C'est dommage, j'en suis bien convaincu. Amha, vous perdez du temps à
écrire des articles comme celui-là ; Ceux qui "choisissent" MySQL n'en
ont rien à faire ...
> Quand à MySQL, ce que j'en pense a été résumé ici : > http://blog.developpez.com/sqlpro/p9136/langage-sql-norme/mysql-un-sgbdr-poudre-aux-yeux/
Je n'ai lu que l'introduction, mais soit c'est obsolète, soit vous ne voyez que ce vous voulez bien voir. Et je ne suis pas pro-MySQL, bien au contraire.
Bon, j'ai lu un peu plus loin, et ce que vous dites est surement vrai ( je ne vais pas tout vérifier ), le seul point qui ne va pas, c'est que tout ce que vous dites, les utilisateurs de MySQL s'en contre-foutent, dans les grandes largeurs, vous n'imaginez même pas. Certains ne savent même pas ce qu'est une clé primaire ...
Et même des utilisateurs de SQL-Server ou Oracle ou DB2 ( que j'ai migré à PostgreSQL ) n'utilisait pas 10% des fonctionnalités que vous décrivez.
Je n'ai jamais vu de CTE chez mes clients, par exemple, ou d'index sur une expression ... Bon évidemment, j'intervenais chez ceux qui avaient des problèmes avec leur SGBD, pas chez ceux qui maitrisaient.
C'est dommage, j'en suis bien convaincu. Amha, vous perdez du temps à écrire des articles comme celui-là ; Ceux qui "choisissent" MySQL n'en ont rien à faire ...
