Discussions apparemment similaires...
Discussion : Auteur Réponses : Affichages : Dernier message
  Comment optimiser une grosse application Javascript Sephi-Chan 9 283 09-07-2009 04:45 PM
Dernier message: QuentinC
:heu: Grosse(s) table(s) (nouveaux éléments) manip 32 936 09-14-2008 02:29 PM
Dernier message: Kassak

Poster une réponse 
 
Note de cette discussion :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
[SQL] couper une grosse table en plusieurs tables
Auteur Message
php_addict Hors ligne
Membre

Messages : 187
Inscription : Oct 2009
Réputation : 0
Message : #21
[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 16

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 34

ou de crypter les données sensibles de l'url...
02-08-2010 07:02 PM
Trouver tous les messages de cet utilisateur Citer ce message dans une réponse
NicoMSEvent Hors ligne
Membre

Messages : 879
Inscription : Dec 2006
Réputation : 8
Message : #22
[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 16 )
je préfère mon système 16

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
Visiter le site internet de cet utilisateur Trouver tous les messages de cet utilisateur Citer ce message dans une réponse
Allwise Hors ligne
Membre

Messages : 324
Inscription : Jan 2009
Réputation : 5
Message : #23
[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 57
02-09-2010 04:13 PM
Trouver tous les messages de cet utilisateur Citer ce message dans une réponse
Poster une réponse 



ContactJeuWeb - Crée ton jeu par navigateurRetourner en hautRetourner au contenuVersion bas-débit (Archivé)Syndication RSS