Efficacité table sql

[Melimelo]

Tu fais 4 Requête pour afficher ton menu O_o

[biboum]

Bah ce que j'appelle menu, c'est l'enveloppe de la messagerie qui dit s'il y a des messages, c'est le nombre de joueur en ligne, c'est les diverses protection (s'il a bien choisit un personnage, s'il a bien choisit un pays, etc)
Le menu en lui même n'a pas besoin ...y a aussi les données perso du joueur (PIB, science, point armée, etc).

Y a pas ca chez vous ?

[wild-D]

Bah ce que j'appelle menu, c'est l'enveloppe de la messagerie qui dit s'il y a des messages, c'est le nombre de joueur en ligne, c'est les diverses protection (s'il a bien choisit un personnage, s'il a bien choisit un pays, etc)
Le menu en lui même n'a pas besoin ...y a aussi les données perso du joueur (PIB, science, point armée, etc).

Y a pas ca chez vous ?

ben j'en suis encore à la conception.
Et effectivement pour la messagerie interne et autres trucs interactif (avec interaction entre plusieurs joueurs). J'ai le même soucis de "multiplier" les requête

par contre pour les données du joueur, là ce sera mis en cache session (histoire que l'affichage ne demande pas de requêtes; mais bon je suis sur un concept de tour par tour^^ c'est donc un peu différent).

[biboum]

par contre pour les données du joueur, là ce sera mis en cache session (histoire que l'affichage ne demande pas de requêtes; mais bon je suis sur un concept de tour par tour34 c'est donc un peu différent).
==> Idem, ca sera tour/tour, qui deviendras par la suite dans la version XX sur du continue. (1jour reel = 12jours in game)

Mis en cache session ? C'est a dire ? Que lors de l'identification, on mette les donnée dans une $_SESSION ?

[wild-D]

Mis en cache session ? C'est a dire ? Que lors de l'identification, on mette les donnée dans une $_SESSION ?

ouaip tout ce qui est donnée du joueur très utilisé est mis dans $_SESSION (pseudo, et autres données comme nb de carte du sabot).

[Karedas]

Premièrement. Jamais de redondance de données tu feras !

Il est effectivement important d'enfoncer à coup de marteau les formes normales de Codd dans le cerveau des apprentis DBA.
Mais attention, ces derniers temps de plus en plus de DBA militent pour une dénormalisation des bases dans certains cas.
Si tu est sûr d'avoir besoin du nom du client dans 100% des appels de la table facture, alors il peut être envisageable d'y mettre en dur le nom du client, afin d'éviter une jointure systématique.

C'est une hérésie je te l'accorde, mais apparement, ça ferait vraiment gagner en rapidité dans certains cas.

[Karedas]

Sans doute de très très rare cas

Des que tu fais du reporting par exemple, une table de log qui n'a pas vocation à recevoir des update doit être dénormalisée.

Je vais te citer un autre exemple rencontré au boulot.
Une facture, légalement, doit porter l'adresse du client au moment de son édition.
Si un client déménage:
1- tu gère les adresses des clients en dehors de la table client et tu as dans la facture une référence à la ligne d'adresse et non de client (c'est capilotracté)
2- tu crée un nouveau client pour chaque déménagement (si tu gère les clients actifs/inactifs ça va mais ça reste bof)
3- tu dénormalise et inscrit les coordonnées client en clair dans la facture, ainsi quoi qu'il arrive une réédition de ta facture est légalement juste.