Je ne sais pas trop si je dois écrire ce message sur user ou ici, comme il s'agit de la svn je vais plutôt écrire ici, que les purs développeurs daignent m'accorder un regard bienveillant
Ce mois d'août fût un peu difficile pour moi :
- mise à jour de mysql en version 5 sur mon serveur avec dans la suite (entre autre) les tables spip d'indexations crashées et non réparables (j'ai détruit et réindexé, ça marche).
- passage en svn d'alors sans trop de problème
- constat : lors des ces manips j'ai visiblement perdu un millier de mes auteurs dans spip_auteurs! (je n'ai $pas$ touché à cette table je le jure)
- j'ai fait un état des lieux de ma base mysql avec phpMyAdmin et j'avais des erreurs du type :
" Il y a des problèmes avec les index de la table `spip_index`
La colonne `id_table` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index "
Pour quatre tables cela concernait des programmes devenus inutiles donc j'ai viré, pour spip_index _fil_ m'a dit la même chose sur irc et effectivement la mise à jour en svn l'a virée.
Toutefois il me reste un dernier message d'erreur pour spip_versions :
" Il y a des problèmes avec les index de la table `spip_versions`
La colonne `id_article` ne devrait pas faire partie à la fois d'une clé primaire et d'une clé index "
Est-ce un problème lié à spip ou bien est-ce que le passage à mysql 5.0 m'a vraiment perturbé autant de choses?
Et dans tous les cas avez vous des suggestions? (Je pense faire la mise à jour de mysql en 5.1 dès qu'elle ne sera plus en bêta).
C'est une remarque de MySQL qui ne doit pas être problématique en soi (PostGres s'en accomode alors qu'il est plus pointilleux queMySQL) mais qui est intéressante: maintenant que je comprends mieux comment les serveurs SQL utilisent les index, celui-ci me parait effet inutile voire nuisible. Je vais le retirer.
Toutefois il me reste un dernier message d'erreur pour spip_versions :
" Il y a des problèmes avec les index de la table `spip_versions`
La colonne `id_article` ne devrait pas faire partie à la fois d'une
clé primaire et d'une clé index "
Est-ce un problème lié à spip ou bien est-ce que le passage à mysql
5.0 m'a vraiment perturbé autant de choses?
C'est une remarque de MySQL qui ne doit pas être problématique en soi (PostGres s'en accomode alors qu'il est plus pointilleux queMySQL) mais qui est intéressante: maintenant que je comprends mieux comment les serveurs SQL utilisent les index, celui-ci me parait effet inutile voire nuisible. Je vais le retirer.
oui, j'ai ca aussi sur mots partout si je fais :
PRIMARY KEY (`$id_chose`,`id_mot`), KEY `$id_chose`
du coup, je fais :
PRIMARY KEY (`id_mot`,`$id_chose`),KEY `$id_chose`
et je n'ai pas le warning
mais en fait, je voulais plutot faire :
PRIMARY KEY (`id_mot`,`$id_chose`),KEY `$id_chose`,KEY `id_mot`
PRIMARY KEY (`id_mot`,`$id_chose`),KEY `$id_chose`
et je n'ai pas le warning
mais en fait, je voulais plutot faire :
PRIMARY KEY (`id_mot`,`$id_chose`),KEY `$id_chose`,KEY `id_mot`
c'est quoi le mieux ?
la 2e forme est redondante, car un clé composée A,B, si j'ai bien compris, est comme une clé simple A à ceci près que chaque feuille de son arbre est l'arbre de la clé B limité à la portion de la table dont le champ A correspond à ce point de l'arbre A. Donc toutes les entrées pour une certaine valeur de A sont données *aussi* par la clé composée A,B, pas besoin de redéclarer un index sur A. Mais il faut remarquer que cela n'est pas vrai pour les entrées de B: la clé composée B,A n'est pas équivalente à A,B précisément à cause de ça: les entrées de B d'une certaine valeur sont rangées selon les valeurs de A dans l'index A,B, donc pas ensemble a priori. Ca a donc un intérêt de déclarer l'index B, pas l'index A et c'est pourquoi il y a un warning si on le fait pour A, mais pas si on le fait pour B.
