24-09-2008, 06:12 PM
Bon si j'ai bien compris c'est ton navigateur (et non celui de sjoueurs) qui fait tourner le javascript qui met à jour les données dans la bdd.
Il serait déjà plus éfficace de faire un script php qui tourne sans fin, grace à une boucle ou à la fin tu utiliserais la fonction sleep(); de php qui permet d'attendre un certains nombre de seconde...
Mais même çà il ya un hic, tu aurra des UPDATE toutes les secondes, donc test tables vont être très souvent vérouillé en écriture comme c'est déjà le cas avec ton système.
Ca entrainera des lenteurs.
Et c'est bien pour çà que Pascal te conseillait de lire ce sujet
Evidement de prime abord ce n'est pas adapté à la modélisation de table qui est mauvaise.
En effet rien que le fait d'avoir une table par membre est mauvais, car mysql n'aime pas avoir un trop grand nombre de table. Sans compter les éventuels problème liées au membre qui s'appelerait par le nom d'une autre table, ou un mot interdit en mysql "force", "as", "o'neil" (enfin effectivement tout ceci peut se filtrer)
La question c'est pourquoi tu ne réunirais pas tes tables membres en une seul table `membres`
nom_membre, type, production_lvl,stockage_lvl,points,ressources,troupes,maximum,vitesse
Sachant que tu arrais plusieurs lignes avec des nom_membres identiques.
Il faudrait penser à mettre une clef de type index afin d'accélérer la recherche dans cette table
Ce serait encore mieux.
Mais çà ne serait qu'une réparation de fortune.
Pour moi il faut revoir entierement la conception de ta base de donnée tant qu'il en est encore temps, sinon tu sera obligé de faire une v2 (dans le sens de repartir à 0) avant même la sortie d'une betatest.
Là tu crées des tables fourre tout. C'est ce que sont tes tables $membre, car elle mélange les troupes, avec les ressources.
D'ailleurs quand on regarde, on voit des cases vide qui montre qu'il ne s'agit pas de la même chose
Donc effectivement faut que tu vois une modélisation de table qui soit bonne, le mieux srait de nous expliquer un peu ton jeu, afin qu'on le ensemble à partir de tes spécification ce qui ferait au passage un bon tuto sur le sujet.
Il serait déjà plus éfficace de faire un script php qui tourne sans fin, grace à une boucle ou à la fin tu utiliserais la fonction sleep(); de php qui permet d'attendre un certains nombre de seconde...
Mais même çà il ya un hic, tu aurra des UPDATE toutes les secondes, donc test tables vont être très souvent vérouillé en écriture comme c'est déjà le cas avec ton système.
Ca entrainera des lenteurs.
Et c'est bien pour çà que Pascal te conseillait de lire ce sujet
Evidement de prime abord ce n'est pas adapté à la modélisation de table qui est mauvaise.
En effet rien que le fait d'avoir une table par membre est mauvais, car mysql n'aime pas avoir un trop grand nombre de table. Sans compter les éventuels problème liées au membre qui s'appelerait par le nom d'une autre table, ou un mot interdit en mysql "force", "as", "o'neil" (enfin effectivement tout ceci peut se filtrer)
La question c'est pourquoi tu ne réunirais pas tes tables membres en une seul table `membres`
nom_membre, type, production_lvl,stockage_lvl,points,ressources,troupes,maximum,vitesse
Sachant que tu arrais plusieurs lignes avec des nom_membres identiques.
Il faudrait penser à mettre une clef de type index afin d'accélérer la recherche dans cette table
Ce serait encore mieux.
Mais çà ne serait qu'une réparation de fortune.
Pour moi il faut revoir entierement la conception de ta base de donnée tant qu'il en est encore temps, sinon tu sera obligé de faire une v2 (dans le sens de repartir à 0) avant même la sortie d'une betatest.
Là tu crées des tables fourre tout. C'est ce que sont tes tables $membre, car elle mélange les troupes, avec les ressources.
D'ailleurs quand on regarde, on voit des cases vide qui montre qu'il ne s'agit pas de la même chose
Donc effectivement faut que tu vois une modélisation de table qui soit bonne, le mieux srait de nous expliquer un peu ton jeu, afin qu'on le ensemble à partir de tes spécification ce qui ferait au passage un bon tuto sur le sujet.