15-12-2008, 11:47 AM
Plusieurs réfléxions que je me fait comme ça:
- j'aurais mis tous les éléments de carte dans une seule table, là les infos latitude et longitude sont réparties dans x tables, (imagine que pour des raisons de reporting tu veuille savoir combien tu as d'éléments sur une case, ou une moyenne) j'aurais donc vu: id,type,latitude, longitude, ensuite tu join avec les table de chaque type. exemple:
et dans type tu met un integer correspondant à chaque type d'éléments.
Tu as quoi comme info qui diffère entre ces 4 type ?
- En effet pour le décor un système de cache c'est pas mal. Mieux que cacher les infos, je cacherais l'image. Si ton décor ne change pas toutes les 5 minutes, quand quelqu'un passe sur une case tu génère une image de la carte à 5 cases alentours, et tu la mets en cache, tu la regénère que si tu n'as pas d'image de moins de X jours. Au pire tu peux générer automatiquement dès qu'un élément de décor change. Bon pour ce genre de truc c'est pas du luxe d'avoir un serveur pour les média.
-pourquoi le nombre de requête par page influe-t-il sur ta limite de connexions simultanées, normalement on ouvre en début de script, on ferme en fin, donc un script->une connexion, peut importe le nombre de requêtes.
- si tu a plusieurs requête à récupérer dans un seul tableau, utilise une fonction au sein de ta base de données, dans cette fonction, tu lance toutes tes requêtes et les réuni en un seul recordset.
-Règle à garder en tête quand on tape des commandes sql, si elle prend plus de 50ms, retravaillles là.
Tes tables sont elles indexées sur les latitudes et longitudes ?
Lance chacune des requêtes précédées de "explain " dans ton interface de gestion de bdd et donne nous les résultats, ça peut aider.[/quote]
- j'aurais mis tous les éléments de carte dans une seule table, là les infos latitude et longitude sont réparties dans x tables, (imagine que pour des raisons de reporting tu veuille savoir combien tu as d'éléments sur une case, ou une moyenne) j'aurais donc vu: id,type,latitude, longitude, ensuite tu join avec les table de chaque type. exemple:
Citation :rpg coffers (champs : name, longitude, latitude)rpg_map (champs: name,longitude,latitude,type)
rpg_towns (champs : name, longitude, latitude)
rpg_teleportations (champ : name, longitude, latitude)
rpg_packages_offices (champs : name, longitude, latitude)
et dans type tu met un integer correspondant à chaque type d'éléments.
Tu as quoi comme info qui diffère entre ces 4 type ?
- En effet pour le décor un système de cache c'est pas mal. Mieux que cacher les infos, je cacherais l'image. Si ton décor ne change pas toutes les 5 minutes, quand quelqu'un passe sur une case tu génère une image de la carte à 5 cases alentours, et tu la mets en cache, tu la regénère que si tu n'as pas d'image de moins de X jours. Au pire tu peux générer automatiquement dès qu'un élément de décor change. Bon pour ce genre de truc c'est pas du luxe d'avoir un serveur pour les média.
-pourquoi le nombre de requête par page influe-t-il sur ta limite de connexions simultanées, normalement on ouvre en début de script, on ferme en fin, donc un script->une connexion, peut importe le nombre de requêtes.
- si tu a plusieurs requête à récupérer dans un seul tableau, utilise une fonction au sein de ta base de données, dans cette fonction, tu lance toutes tes requêtes et les réuni en un seul recordset.
-Règle à garder en tête quand on tape des commandes sql, si elle prend plus de 50ms, retravaillles là.
Tes tables sont elles indexées sur les latitudes et longitudes ?
Lance chacune des requêtes précédées de "explain " dans ton interface de gestion de bdd et donne nous les résultats, ça peut aider.[/quote]