Comme Sephi-Chan et comme je l'ai dit avant il est important de prendre en compte la maintenabilité du code, et là je pense avoir donné mon avis. Maintenant, si on ne regarde que le coté performance qui semble faire le plus débat:
Pour les formats de ligne fixe il faut qu'il n'y est pas de type varchar, blob ou text.
De même:
Pour modifier çà http://dev.mysql.com/doc/refman/5.0/fr/table-cache.html
Enfin ce qui a été dis à propos du verrouillage et du fait d'attendre que les update se terminent est vrai, MAIS:
Donc si tu as une table ou plusieurs table c'est la même chose! Puisque si il y a un UPDATE il y aura verrou et çà bloquera ta requête SELECT multiple.
Du coup sur ce plan aucun apport d'avoir plusieurs tables, sauf si tu met en place un système de cache par exemple en mettant en cache en session ce qui ne change pas souvent nom,type etc...
Il faut aussi savoir que les suppressions prendront plus de temps avec 3 tables car il faudra éditer les 3 index (qu'il ne faut surtout pas que tu oublis de mettre sinon cette discussion est ridicule...).
Enfin ce qui est important c'est que tu ai compris les remarques faite afin que tu puisses choisir en fonction de l'utilisation que tu comptes faire.
En fait je pense qu'il nous manque la fréquence de mise à jour des ressources pour savoir ce qui est le mieux.
Idée: tu pourrais éventuellement créer une vue qui avec ton timestamp calculerais en temps réel(ou pas) les ressources actuel, tu n'aurais ainsi pas besoin de faire ces UPDATE sauf dans le cas de l'utilisation des ressources (cas que tu n'as pas précisé)
Donc çà résoudrais ton problème d'update... puisqu'il n'y en aurai plus!
Enfin je trouve que çà fait beaucoup d'octet écris pour peut etre des optimisation qui ne sont pas prioritaire (même si à faire au début).
mysql a écrit :Normalement, cela ne sert à rien de séparer une table en différentes tables plus petites, juste parce que vos lignes deviennent grosses. Pour accéder à une ligne, le plus long est le temps d'accès au premier octets de la ligne. Après cela, les disques modernes vont lire très rapidement la ligne, et suffisamment pour la plus par des applications. Le seul cas où cela peut être important est si vous êtes capables de dégager une table à format de ligne fixe (voir ci-dessus), ou si vous avez besoin de scanner régulièrement la table, mais que vous n'avez pas besoin de toutes les colonnes. See Chapitre 14, Moteurs de tables MySQL et types de table.
Pour les formats de ligne fixe il faut qu'il n'y est pas de type varchar, blob ou text.
De même:
mysql a écrit :Si vous avez beaucoup de fichiers dans un dossier, les opérations d'ouverture, fermeture, et création seront ralenties. Si vous exécutez une requête SELECT sur plusieurs tables, il y aura une légère perte lorsque le cache de tables sera plein, car pour chaque table ouverte, une autre doit être fermée. Vous pouvez réduire cette table en augmentant la taille du cache de tables.
Pour modifier çà http://dev.mysql.com/doc/refman/5.0/fr/table-cache.html
Enfin ce qui a été dis à propos du verrouillage et du fait d'attendre que les update se terminent est vrai, MAIS:
Citation :Pour le fonctionnement c'est simple j'ai besoin des informations du terrain : location, nom, id, type, superfice, emplacements + des ressources : or, metal, pierre, bois, timestamp + les taux de chaques ressources (4 pour 4 ressources) sur chaque page. Pour ce qui est de la mise à jour, il n'y que les ressources qui sont mise à jour tout le temps. Le nom du terrain change ainsi que les taux de productions seulement si le joueur décider de changer lui même.Donc sur chaque page tu demandes toutes les infos des 3 tables.
Donc si tu as une table ou plusieurs table c'est la même chose! Puisque si il y a un UPDATE il y aura verrou et çà bloquera ta requête SELECT multiple.
Du coup sur ce plan aucun apport d'avoir plusieurs tables, sauf si tu met en place un système de cache par exemple en mettant en cache en session ce qui ne change pas souvent nom,type etc...
Il faut aussi savoir que les suppressions prendront plus de temps avec 3 tables car il faudra éditer les 3 index (qu'il ne faut surtout pas que tu oublis de mettre sinon cette discussion est ridicule...).
Enfin ce qui est important c'est que tu ai compris les remarques faite afin que tu puisses choisir en fonction de l'utilisation que tu comptes faire.
En fait je pense qu'il nous manque la fréquence de mise à jour des ressources pour savoir ce qui est le mieux.
Idée: tu pourrais éventuellement créer une vue qui avec ton timestamp calculerais en temps réel(ou pas) les ressources actuel, tu n'aurais ainsi pas besoin de faire ces UPDATE sauf dans le cas de l'utilisation des ressources (cas que tu n'as pas précisé)
Donc çà résoudrais ton problème d'update... puisqu'il n'y en aurai plus!
Enfin je trouve que çà fait beaucoup d'octet écris pour peut etre des optimisation qui ne sont pas prioritaire (même si à faire au début).