+- 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 : [SQL] couper une grosse table en plusieurs tables (/showthread.php?tid=4578)
RE: [SQL] couper une grosse table en plusieurs tables - php_addict - 08-02-2010
(08-02-2010, 03:10 PM)NicoMSEvent a écrit : je me serts des ID pour stocker les positions des personnages (dans la table perso, j'ai l'ID de la case), les pnj, les magasins, les autes, ...
ce n'est certainement p-e pas la meilleure des solutions, mais pour l'instant ça me convient
tu peut stocker x et y au lieu de l'id, mais cela ne doit pas changer grand chose...
(08-02-2010, 03:10 PM)NicoMSEvent a écrit : Dans mes URL, plutot que de dire : "je me déplace vers la case XYZ", je préfère dire "je vais vers le sud-ouest". Il y a moins de vérification point de vue possibilité de triche ^^
ou de crypter les données sensibles de l'url...
RE: [SQL] couper une grosse table en plusieurs tables - NicoMSEvent - 08-02-2010
(08-02-2010, 07:02 PM)php_addict a écrit : tu peut stocker x et y au lieu de l'id, mais cela ne doit pas changer grand chose...ça facilite les calculs pour les distances... 2 jointures en moins pour retrouver la distance entre x,y (ex : entre 10,10 et 100,10 -> 90)
plutot que id:11235 et id:2598 qu'il faut traduire en coordonnées x,y
(08-02-2010, 07:02 PM)php_addict a écrit : ou de crypter les données sensibles de l'url...si on crypte, ça prends un peu de puissance de calcul tout au long de la chaine (crypter d'un coter, décrypter de l'autre, sans compter que celui qui arrive a casser le code pourrait tricher
)je préfère mon système
RE: [SQL] couper une grosse table en plusieurs tables - Allwise - 09-02-2010
Argorate a écrit :En théorie, si on a un bon SGBD il est censé s'occuper tout seul de faire les jointure avant les autres clauses WHERE (du moins c'est se qu'on nous a enseigné)En fait le SGBD optimise l'ordre d'exécution des jointures, qui peut donc être différent de l'ordre dans lequel elles apparaissent dans la requête. Si des clauses WHERE portent sur des tables issues de jointures, il les traitera effectivement en même temps que la jointure.
J'ai jamais essayé de voir si mysql était optimisable de se coté là, faudra que je test.
Par exemple, un
Code :
SELECT * FROM
a
INNER JOIN b ON a.id=b.id
WHERE b.id>100est équivalent à
Code :
SELECT * FROM
a
INNER JOIN b ON a.id=b.id AND b.id>100Il optimise aussi le choix des index utilisés, qui peut malgré tout être forcé avec USE KEY(mon_index).
Vive la commande EXPLAIN pour l'optimisation des requêtes :glace: