Grosse(s) table(s) (nouveaux éléments)

[Cartman34]

+1

PS: j'aime pas le flood mais Sephi-Chan a raison.

[Zamentur]

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:

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:

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:

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).

[manip]

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.

[pascal]

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 ?

[Zamentur]

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`; 

[pascal]

et si les données sont cachées en session, on économise encore une requête par page.

A+

Pascal

[Zamentur]

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`; 

[Cartman34]

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.

[Zamentur]

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() !

Le problème est qu'on ne peut pas mettre un time() pour la vue... Puisque çà change à chaque appel de la vue!

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é.

[Sephi-Chan]

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