Discussion :

[Baud10]

Bonjour

J'utilise MySQL 4 et quelques (sur mon OVH mutualisé) lequel j'administre depuis phpmyadmin et j'utilise donc exclusivement en PHP.

Je n'ai qu'un espace de mémoire limité, c'est pour ça que je grapille chaque octets.

Première question :
Dans phpMyAdmin justement, lors de l'affichage de la structure d'une table, il affiche les types suivie de leur "taille". Cette taille est en octets ?

Je m'explique : D'après PhpMyAdmin, un int mesure 10 octets, un bigint(20), mediumint(8), smallint(5), tinyint(3). D'après la documentation de MySQL (http://dev.mysql.com/doc/refman/5.0/...uirements.html), cela devrait être 4, 8, 3, 2, 1 au lieu de 20, 10, 8, 5 3 respectivement.
Faut-il que je modifie manuellement chaque colonne avec la bonne taille en octets ?

Seconde question :
A partir de quelle taille d'après vous, est-il plus judicieux d'utiliser un VARCHAR(X) au lieu d'un CHAR(X) ?

Troisième question :
J'ai lu dans l'explication de l'optimisation des requêtes LEFT JOIN (http://dev.mysql.com/doc/refman/5.0/...imization.html), les conditions de la clause ON sont transformées en WHERE.
Sont-elles simplement ajouté au WHERE de la requête principale (ce qui revient a faire une jointure naturelle (produit cartésien), et appliquer la sélection de ligne après) ?
En gros ma question est : est-ce intéressant de remplacer systématiquement chaque jointure naturelle par un LEFT JOIN quand cela est possible ?

Quatrième question :
Mes tables sont enregistré aux format du moteur MyISAM. J'ai le choix entre: MyISAM, MERGE, HEAP, MEMORY et ISAM. J'imagine que c'est le meilleure pour MySQL 4 ?

Cinquième question :
Si je n'ai pas besoin de requêtes imbriquées (sous requêtes), de clés étrangères ou je ne sais quoi, est-ce qu'il est intéressant de passer à MySQL 5 ? (point de vu vitesse d'exécution des requêtes ?)

Merci d'avance !

[Fabrice MEMBRÉ]

1er question :
Oui, il est souhaitable que les tailles soient adaptés à leur usage et au CPU de la machine.

2eme question :
Pour moi, Il est toujours judicieux d'utiliser un varchar sauf sur des codes courts et indexés.

3eme question :
Left join consiste à sortir les lignes de résultat que la jointure existe ou n'existe pas. Faire une jointure naturelle assisté d'un where ne pourra pas donner l'équivalent d'un left outer join mais d'un inner join.
De plus même si on sait que le résultat est équivalent d'un inner join, il est pour moi souhaitable d'utiliser les join pour les jointures et le where pour le filtrage.

4eme question :
Oui.

5eme question :
En terme de vitesse d'execution, il est souhaitable de rester à MyISAM. Celui-ci reste plus rapide que innoDB car il ne gère pas les transactions.

Si ton utilisation de MySQL est dédié à la lecture d'information, reste avec MyISAM. Par contre, si tu dois faire des écritures simultanées sur la base de données, il est souhaitable d'utilisé un moteur ACID comme innoDB.

En espèrant t'aider un peu dans tes choix.

[CinePhil]

2eme question :
Pour moi, Il est toujours judicieux d'utiliser un varchar sauf sur des codes courts et indexés.

Un VARCHAR est parfois inutile. Sur le code postal d'adresses françaises par exemple où un CHAR(5) sera plus judicieux. Ou toute autre sorte de code où le nombre de caractères est constant.

3eme question :
Left join consiste à sortir les lignes de résultat que la jointure existe ou n'existe pas. Faire une jointure naturelle assisté d'un where ne pourra pas donner l'équivalent d'un left outer join mais d'un inner join.
De plus même si on sait que le résultat est équivalent d'un inner join, il est pour moi souhaitable d'utiliser les join pour les jointures et le where pour le filtrage.

Exact. C'est de plus la norme depuis 1992. Il est temps de s'y mettre ! Et ce pour plusieurs raisons maintes fois débattues sur ce forum (lisibilité, débogage, évitement d'erreurs de jointure...).

5eme question :
En terme de vitesse d'execution, il est souhaitable de rester à MyISAM. Celui-ci reste plus rapide que innoDB car il ne gère pas les transactions.

Si ton utilisation de MySQL est dédié à la lecture d'information, reste avec MyISAM. Par contre, si tu dois faire des écritures simultanées sur la base de données, il est souhaitable d'utilisé un moteur ACID comme innoDB.

Sauf qu'apparemment, InnoDB ne lui est pas proposé, pas plus que sur Free d'ailleurs !
Et InnoDB présente aussi le gros avantage sur MyISAM d'accepter les contraintes de clés étrangères.

[Baud10]

Je vous remercie pour ces renseignements qui me sont fort utiles, même si j'en veux à phpMyAdmin de mal mesurer la taille des entiers GRR!

Bon maintenant, migration vers MySQL 5.0.44

[Sivrît]

Je vous remercie pour ces renseignements qui me sont fort utiles, même si j'en veux à phpMyAdmin de mal mesurer la taille des entiers GRR!

Bon maintenant, migration vers MySQL 5.0.44

Ce n'est pas phpMyAdmin mais la norme SQL qu'il faut maudire. Les tailles font références aux nombres de chiffres. Par exemple, un tinyint sur un octet ça fait de 0 à 255, donc 3 chiffres.