Comment gérer les pré requis des bâtiments ?

[dryzd]

Merci de vos réponses, c'est très utile !

Je ne connais pas JSON, et par économie de temps, je serai plutôt sur une base mysql ou fichier :p
Même si Json est sûrement la meilleure solution, on ne peut pas tout faire et tout savoir, faut faire des choix ...

Il me reste une question sans réponse

"Comment je fais pour savoir si le joueur peu construire le bat 1 ?
Il faut regarder pour chacun des bat (1, 2 et 3) si ils ont le niveau requit ?
Et on boucle sur tous les autres bâtiments pour savoir si pour chacun de leurs pré requis sont atteints (avec à chaque fois la boucle ci-dessus) ?"

A tout de suite

[Sephi-Chan]

Désolé de dire ça, mais vous êtes bidons à parler de mise en cache et performances alors que vous faîtes des horreurs (oui, oui) sans forcément réfléchir.

Vous devriez de faire les choses correctement dans un premier temps. Avec des tables de relations. Ensuite, posez-vous les bonnes questions.

Par exemple : avez-vous besoin d'accéder aux dépendances de construction sur chaque page ? Si oui, vous n'avez qu'à mettre en cache le contenu HTML pour générer l'arbre, vous n'aurez pas plus performant (et lancer les requêtes uniquement si ce cache n'existe pas). Si non, vous n'avez même pas besoin de mettre ça en cache.

En général, vous aurez besoin de vos dépendances 2 fois : quand on consulte les dépendances et quand on construit un bâtiment (pour vérifier que le joueur a bien commandé un bâtiment auquel il a accès).

Ceux qui proposent des solutions exotiques, je serais curieux de voir le code source de votre jeu. Ca doit être sympa à maintenir.
Diffusez vos sources, vous y gagnerez.


Sephi-Chan

[atra27]

Tout depend de ton architecture en fait...
Mais oui un simple foreach sur les batiments nécéssaire qui regarde si on a le batiment correspondant pour chaque batiment nécéssaire...

Sinon il y a toujours l'option mysql du where dont je t'ai parlé plus haut!

Edit: Mouaip ecoute moi je vois que pour moi sa marche mes horreurs...
Je travaille trop avec des fichiers et sa plais pas a certains... pour moi sql c'est juste le dynamique...
Les relation mysql/fichiers avec des id qui correspondent y a aucun probléme...
Pour info je n'utilise pas non plus innoDB (j'en connais qui vont crier au sacrilége)

Esnuite l'histoire de la jointure j'en ai déjà parlé:

Si tu stocke en SQL, pour afficher les bâtiments dispos, un petit WHERE.
A la construction, tu refait le même WHERE en rajoutant AND id='$iddubatimentdemandé'

Mais aprés on a cité mon exemple avec les fichiers... ->conclusion logique, la solution proposée par l'exemple en sql n'interesse pas, donc on continue a parler avec les fichiers, donc pas de jointure sql...
Mais bon a chaque fois que je passe mon code est traité comme de la merde donc je vais finir par faire comme beaucoup: arriver, poser ma question, lire la réponce et repartir jusqu'au prochain moment ou j'aurai besoin de conseils...

[Shudrum]

Soit tu laissse le cache de mysql gere sa, soit on revient a ma solution: les fichiers...
Mysql c'est bien mais mysql sa consomme... Rien ne vaux un bon fichier pour les donnée statiques (quitte a la limite a le generer depuis des données sql)

Ne néglige pas l'expertise des moteurs sql pour stocker les données, ils font un bien meilleur travail pour les temps d'accès.

[Sephi-Chan]

Edit: Mouaip ecoute moi je vois que pour moi sa marche mes horreurs...
Je travaille trop avec des fichiers et sa plais pas a certains... pour moi sql c'est juste le dynamique...
Les relation mysql/fichiers avec des id qui correspondent y a aucun probléme...
Pour info je n'utilise pas non plus innoDB (j'en connais qui vont crier au sacrilége)

Ça marche… Sans jugement, quel recul as-tu sur tes pratiques ? Si tu en as, en as-tu suffisamment pour les conseiller ?

Tu compliques le simple avec tes systèmes de fichiers statiques (en multipliant les sources de données qui ne sont abstraits d'aucune manière), d'autant que cette idée que le SQL est fait pour le dynamique est complètement fausse (ou alors quelles sont tes sources ?).

Et puis, comme le dit Shudrum, tu peux être sur les mecs de chez MySQL gèrent mieux les fichiers que toi, que moi, que la majorité des gens.

Mais bon a chaque fois que je passe mon code est traité comme de la merde donc je vais finir par faire comme beaucoup: arriver, poser ma question, lire la réponce et repartir jusqu'au prochain moment ou j'aurai besoin de conseils...

Il faut prendre du recul sur les commentaires… Ou présenter du code, ou réaliser que si les pratiques sont si vivement critiquées, c'est peut-être qu'elles sont mauvaises, etc.

Bref, il ne faut pas jouer les victimes et plutôt rebondir.


Sephi-Chan

[atra27]

Ça marche… Sans jugement, quel recul as-tu sur tes pratiques ? Si tu en as, en as-tu suffisamment pour les conseiller ?

Tu compliques le simple avec tes systèmes de fichiers statiques (en multipliant les sources de données qui ne sont abstraits d'aucune manière), d'autant que cette idée que le SQL est fait pour le dynamique est complètement fausse (ou alors quelles sont tes sources ?).

Un fichier est simplement plus rapide a lire qu'une base sql...
Quand on est sur de toujours chercher des données par l'id du champ alors on peut utiliser un tableau par id inclus.

Pour le reste je suis d'accord que sql avec ses where est plus performant...

Il faut prendre du recul sur les commentaires… Ou présenter du code, ou réaliser que si les pratiques sont si vivement critiquées, c'est peut-être qu'elles sont mauvaises, etc.

Bref, il ne faut pas jouer les victimes et plutôt rebondir.

Je vois surtout que j'ai réduit le temps d'execution d'une page en incluant un tableau plutot qu'avec un select WHERE id=1
http://img535.imageshack.us/img535/3996/sanstitrenw.png
Je dis pas que c'est la meilleure solution mais que dans mon cas elle a fait ses preuves...

Y a plein d'autres discutions sur le sujet sur ce forum d'ailleur...

[Shudrum]

J'avais lu sur un bouquin qu'un accès fichier dont les clusters concernés ne sont pas référencés comme dans une base sql par exemple prenait en moyenne 40ms, ce qui est plus long que tes temps d'accès actuels.

Après, la pertinence de ce que je cite n'est pas super élevée, à confirmer par d'autres connaisseurs, là, c'est en plongeant dans ma mémoire.

[php_addict]

Je vois surtout que j'ai réduit le temps d'execution d'une page en incluant un tableau plutot qu'avec un select WHERE id=1
http://img535.imageshack.us/img535/3996/sanstitrenw.png
Je dis pas que c'est la meilleure solution mais que dans mon cas elle a fait ses preuves...

Y a plein d'autres discutions sur le sujet sur ce forum d'ailleur...

je pensais comme toi auparavant, mais economiser quelques millisecondes pour ca ca vaut pas le coup, mettre tes donnes statiques en base de donnée t'offre un meilleur modele relationel...a la rigeur mieux vaut se concentrer sur la gestion des index de tes tables pour grapiller des milisecondes, (je pense a EXPLAIN pour voir comment tes requetes sont oprimisées ou pas du tout...)

enfin bref le principal c'est que ca marche et on est pas tous des super pros

[Sephi-Chan]

Je vois surtout que j'ai réduit le temps d'execution d'une page en incluant un tableau plutot qu'avec un select WHERE id=1
http://img535.imageshack.us/img535/3996/sanstitrenw.png
Je dis pas que c'est la meilleure solution mais que dans mon cas elle a fait ses preuves...

Tu as remarqué des gains avec quelle masse d'utilisateurs ? 1 ? 10 ? 100 ? 1000 ?


Sephi-Chan

[atra27]

basé sur une moyenne
Max 2 users en ligne simultanés
On voit bien le temps d'exec se réduire entre ces deux champs...
Sur un si la différence est aussi palpable, je pense que sur 1000 sa va encore plus se sentir...