+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Grosse(s) table(s) (nouveaux éléments) (/showthread.php?tid=3040)
RE: Grosse(s) table(s) - Cartman34 - 12-09-2008
+1
PS: j'aime pas le flood mais Sephi-Chan a raison.
RE: Grosse(s) table(s) - Zamentur - 12-09-2008
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:
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).
RE: Grosse(s) table(s) - manip - 12-09-2008
Pour la fréquence des mises a jour, c'est change fois que le joueur refresh sa page...
Pour le reste... bah je réfléchis encore ^^ mais je me dis que d'un cote, je devrais mettre les taux de production dans la table des terrains et laisse la table des ressources seules, car elle sera mise à jour beaucoup plus souvent que les deux autres.
RE: Grosse(s) table(s) - pascal - 12-09-2008
manip a écrit :Pour la fréquence des mises a jour, c'est change fois que le joueur refresh sa page...
:omg:
ça fait pas un peu beaucoup, ça ?
RE: Grosse(s) table(s) - Zamentur - 12-09-2008
C'est bien ce que je pensais, l'idée ici est donc de faire du temps réel...
Une vue mysql serait beaucoup plus approprié, exemple pour l'or:
`or``res_or` :quantité de ressource suite au dernier changement (or est un mot clef réservé)
`temps`: timestamp du dernier changement
`taux_or`: le taux depuis le dernier changement
Au lieu de faire un UPDATE à chaque page puis un SELECT
On créer une vue mysql
Code PHP :
<?php
CREATE VIEW `terrain_maj` AS SELECT id,....,(`res_or`+`taux_or`*(UNIX_TIMESTAMP()-`temps`) AS res_or_maj FROM `terrain`;
Ainsi il n'y aura plus besoin de mettre à jour à chaque fois, il suffira de demander la vue:
Code PHP :
<?php
SELECT `id`,...,`res_or_maj` FROM `terrain_maj` WHERE `id`=%d
En gros tu économisera une requête puisque tu devais faire de toute façon la sélection de la table ...
Les 2 moment ou le UPDATE est inévitable c'est quand:
- on utilise l'or produit: dans ce cas il faut récupérer res_or_maj en déduire la valeur utilisée et faire un UPDATE sur `terrain` et non sur la vue `terrain_maj`(qui n'est qu'une vue...). Ne pas oublier de mettre à jour `temps` avec UNIX_TIMESTAMP()
- on change un taux: et oui car si un taux change on doit absolument calculer combien d'or a été produit jusqu'ici puisque l'ancien taux sera écrasé par le nouveau taux. Idem, ne pas oublier de mettre à jour `temps` avec UNIX_TIMESTAMP()
Et avec ce système tu économises tes requêtes de mise à jour tout en gardant un système en temps réel...
RE: Grosse(s) table(s) - pascal - 12-09-2008
et si les données sont cachées en session, on économise encore une requête par page.
A+
Pascal
RE: Grosse(s) table(s) - Zamentur - 12-09-2008
C'est bien ce que je pensais, l'idée ici est donc de faire du temps réel...
Une vue mysql serait beaucoup plus approprié, exemple pour l'or:
`or` `res_or` :quantité de ressource suite au dernier changement (or étant un mot clef réservé je pense)
`temps`: timestamp du dernier changement
`taux_or`: le taux depuis le dernier changement
Au lieu de faire un UPDATE à chaque page puis un SELECT
On créer une vue mysql
Code PHP :
<?php
CREATE VIEW `terrain_maj` AS SELECT `id`,...,(`res_or`+`taux_or`*(UNIX_TIMESTAMP()-`temps` AS `res_or_maj` FROM `terrain`;
Ensuite il suffira de demander le taux et le reste dans les script qui en ont besoin:
Code PHP :
<?php
SELECT ...,`res_or_maj` FROM `terrain_maj` WHERE `id`=%d
Ainsi plus d'update, sauf dans 2 cas:
- l'utilisation des ressources du terrain
- le changement d'un taux (car on perd par conséquent le taux précédent!)
Sur ces 2 update il faut demander res_or_maj (retranché éventuellement la valeur utilisé)
- mettre la nouvelle valeur dans res_or
- mettre à jour temps avec UNIX_TIMESTAMP
- mettre à jour le taux
Le tout peut être fait en une seul requête
RE: Grosse(s) table(s) - Cartman34 - 12-09-2008
Je te déconseille les fonctions MySQL telles que UNIX_TIMESTAMP() car tu ne controles pas grand chose et utilises les ressources de ton serveur mysql.
Vaut mieux une bonne entrée time() !
Perso, j'essaye d'alléger le jeu avec les sessions mais les mises à jour sur chaque page ca passe niquel et c'est ce qu'il y a de plus sur.
RE: Grosse(s) table(s) - Zamentur - 12-09-2008
IGstaff a écrit :Je te déconseille les fonctions MySQL telles que UNIX_TIMESTAMP() car tu ne controles pas grand chose et utilises les ressources de ton serveur mysql.Le problème est qu'on ne peut pas mettre un time() pour la vue... Puisque çà change à chaque appel de la vue!
Vaut mieux une bonne entrée time() !
Sinon je ne comprend pas bien ce qui ne va pas avec UNIX_TIMESTAMP() surtout ce passage "tu ne controles pas grand chose"?
Pour les ressources serveur sql, je ne pensais pas qu'il y avais une différence entre l'utilisation de time et de UNIX_TIMESTAMP()?
En tout cas faire un UPDATE à chaque fois n'est pas ce qu'on appel une solution optimisé. Puisqu'il ne peut y avoir qu'une seul requête d'écriture alors que l'on peut faire de multiple requête de lecture simultané.
RE: Grosse(s) table(s) - Sephi-Chan - 12-09-2008
Je trouve crade d'utiliser un champ INT (ou VARCHAR) pour stocker un timestamp (issu de PHP), si c'est de ça dont il s'agit.
Les fonctions de dates et heures de MySQL ne peuvent pas y être appliquées. Un bon champ TIMESTAMP ou DATETIME convient très bien (et mieux, à mon goût, d'ailleurs), et puis c'est fait pour ça.
Concernant la récupération du timestamp, je ne vois pas quel contrôle on peut vouloir sur ce nombre… :/
Sephi-Chan