php_addict
Membre
Messages : 187
Inscription : Oct 2009
Réputation : 0
|
[SQL] couper une grosse table en plusieurs tables
(02-08-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...
(02-08-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...
|
|
| 02-08-2010 07:02 PM |
|
NicoMSEvent
Membre
Messages : 879
Inscription : Dec 2006
Réputation : 8
|
[SQL] couper une grosse table en plusieurs tables
(02-08-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
(02-08-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
Je signale que je ne détiens pas la vérité unique et absolue, je peux me tromper. La critique peut aussi être constructive. Critiquez moi!
La quête d'Ewilan
Graphismes : 94% Conception : 100% Programmation : 95% Test : 71%
Mise en place des quêtes : 3%
Avancement global : Beta ouverte (équilibrage des mob, construction des villes)
|
|
| 02-08-2010 08:14 PM |
|
Allwise
Membre
Messages : 324
Inscription : Jan 2009
Réputation : 5
|
[SQL] couper une grosse table en plusieurs tables
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é)
J'ai jamais essayé de voir si mysql était optimisable de se coté là, faudra que je test.
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.
Par exemple, un
Code :
SELECT * FROM
a
INNER JOIN b ON a.id=b.id
WHERE b.id>100
est équivalent à
Code :
SELECT * FROM
a
INNER JOIN b ON a.id=b.id AND b.id>100
Il 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
|
|
| 02-09-2010 04:13 PM |
|