+- 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 : Une grosse table ou plusieurs avec jointures (/showthread.php?tid=4820)
Pages :
1
2
Une grosse table ou plusieurs avec jointures - php_addict - 14-05-2010
bonsoir
je suis en train de repenser ma table rapports, et je me permets de solliciter votre avis.
on va dire que pour le moment j'ai:
- une table rapports_pointeur qui recense les rapports et qui dit qui peut lire les rapports
- une table rapports_details, comportant toutes les infos des rapports
cette derniere risque d'etre relativement volumineuse, beaucoup de champs (une 20aine) avec beaucoup d'entrée et de données...
cette table sera bien entendu nettoyée de temps en temps...
comme j'ai plusieurs types de rapports (commerce, attaque, etc...) je me suis dis: pourquoi tu ne fais pas plusieurs table rapports_details mais du coup il risque d'y avoir pas mal de jointures entre table rapports_pointeur et mes table rapports_details
faut il mieux 1 grosse table avec plein de données, plein de champs, plein d'entrées ou plusieurs table avec beaucoup de jointures (entre 5 et 10 jointures) ?
sachant que je ne peut pas prédire à l'avance la volumétrie de mes table car je n'ai pas d'autre joueur que moi pour le moment sur mon localhost (h)
RE: 1 grosse TABLE ou plusieurs avec jointures - Allwise - 15-05-2010
Quand tu dis beaucoup d'enregistrements tu penses à combien ? milliers, centaines de milliers, millions, dizaines de millions ? Sans pouvoir donner un chiffre exact tu devrais quand même pouvoir donner un ordre de grandeur.
Je pense que dans tous les cas il faut que tu partes sur une seule table rapports. À chaque entité sa table. Pas la peine d'avoir plusieurs tables "doublons", c'est pas logique et ça va te compliquer la vie pour rien. Puis est-ce que t'as besoin de conserver tous les rapports, même ceux qui sont vieux de plusieurs semaines / mois / années, ou des purges sont-elles envisageables ? Si t'en as besoin ad vitam eternam, peux-tu envisager de déplacer les données dans une table "archives" ?
Garde une seule table, je pense pas que arrives aux limites de MySQL, qui est très costaud est très à l'aise avec des tables de plusieurs millions d'enregistrements, pourvu que les requêtes tirent parti des bons index de la table. Faire des jointures ne changera rien, si tu déportes des données dans d'autres tables et que tu te retrouves avec des tables de relation 1:1, le même nombre d'enregistrement sera parcouru mais tu auras des ouvertures de fichiers en plus par rapport à une structure avec une table. Et si tu crées une table par type de rapport par exemple, je suis pas sûr que tu y gagnes de la performance par rapport au schéma traditionnel avec de bons index. Et si jamais le problème de volumétrie devait se poser un jour, c'est un "problème de riche". Tu optimiseras ton application à ce moment-là, mais inutile de chercher à sur-optimiser son appli pour des problèmes qui n'existent pas, ça va 1° te faire perdre du temps, 2° potentiellement créer de nouveaux problèmes, voire avoir l'effet l'inverse, 3° être inutile parce que le besoin n'existera (peut-être) jamais
RE: 1 grosse TABLE ou plusieurs avec jointures - php_addict - 15-05-2010
(15-05-2010, 12:42 AM)Allwise a écrit : Quand tu dis beaucoup d'enregistrements tu penses à combien ? milliers, centaines de milliers, millions, dizaines de millions ?
300.000 ou 400.00 maxi...
(15-05-2010, 12:42 AM)Allwise a écrit : des purges sont-elles envisageables ?
oui bien sur, c'est pas encore fait mais ca le sera.
merci pour ton avis éclairé, n'ayant jamais eu de grosee BD je ne pensais pas pas que mysql etait si robuste...je vais donc garder ma grosse tale ;-)
merci encore
bonne journée
RE: Une grosse table ou plusieurs avec jointures - Argorate - 15-05-2010
J'ai une table (celle de ma map) avec plus de 2.4 millions d'enregistrement et ça n'a jamais était un problème pour l'instant
Tout dépend le nombres d'informations et si tu en as souvent besoin etc...
Si seuleuement certaines informations sont solicitées 90% du temps, effectivement tu peux découper en deux tables pour améliorer un peu les perf, mais faut voir si ça en vaut vraiment la peine.
RE: Une grosse table ou plusieurs avec jointures - atra27 - 16-05-2010
Mysql ne ralentis pas trop suivant le nombre d'enregistrements...
L'utilité de plusieurs tables c'est de séparer les domaines d'actions et de le récuperer que ce dont on a besoin.
Par exemple si un user peut avoir 10 vaisseaux, tu fait des champs pour les 10 vaisseaux, mais tu va stocker les caractéristiques de ces vaisseaux dans une autre table... ->jointure
Si le nombre de vaisseau est infini, alors tu va stocker l'id du proprio dans ta table vaisseau pour chaque vaisseau...
Maintenant toutes les infos sur le perso lui méme, je te conseille de les mettre dans ta table user... c'est plus simple pour cacher ces données...
Par exemple j'utilise une class SQL qui me permet d'executer une requete et d'en retourner le résultat sous forme de tableau en une seule ligne
Pour ma table user, j'ai fait comme sa sur mon index!
Code PHP :
<?php
if(isset($_SESSION['sqlcache']['sv_user']){//si cache sql de la table user defini
$data=$_SESSION['sqlcache']['sv_user'];//recupére contenu dans data
}else{
$data=$db->fetch('SELECT * FROM sv_user where id=1');//sinon requete sql
$_SESSION['sqlcache']['sv_user']=$data;//puis mise en cache pour aprés
}
Et pour ma fonction d'update, j'ai simple ajouté une ligne:
Code PHP :
<?php
unset($_SESSION['sqlcache'][ $tablename ]);
Couplé avec le gestionnaire de session en POO donné sur le wiki et avec un champ pour stocker l'id de session en bdd on peut quand méme unset sur une autre session :p mais la j'ai simplifié au max sinon sa devient vraiment compliqué sans avoir tout le code sous les yeux.
Voila donc l'utilité que je vois d'une seule table: cacher le résultat!
RE: Une grosse table ou plusieurs avec jointures - Anthor - 16-05-2010
Quitte à utiliser les sessions, autant faire une classe qui utilise un fichier, et est disponible pour tous. ^^
RE: Une grosse table ou plusieurs avec jointures - atra27 - 16-05-2010
Dépend de l'utilité qu'on en as.
les informations en cache ne peuvent êtres modifiées que par l'user courant donc j'ai pas l'utilité d'un tel système...
Les autres se rechargent par dessus le cache avant l'affichage...
RE: Une grosse table ou plusieurs avec jointures - Anthor - 16-05-2010
Quel que soit l'utilité, faire un cache session pour ça n'a aucune utilité ^^
RE: Une grosse table ou plusieurs avec jointures - atra27 - 16-05-2010
heu si sa en as une sinon j'aurai pas codé ça
Comme on dit, les choses on l'importance qu'on leur donne mais la je dois dire que sa a une utilité réelle. :p
Sa m'économise une requête par page, et mettre en cache le tableau de la requête complète permet pour moi une meilleure utilisation.
Mon buffer sql s'appelle $data dans tous mon jeu, j'ai juste a charger $data depuis la session (et pas depuis la requête sql) et tout le reste fonctionne pareil
De la même façon je cache toutes mes requêtes ou je sélectionne tous les champs (*) et ou l'id de l'user est demandé dans le where...
Sa permet de mettre grosso modo une seule fois en session des données telles que la position du joueur, son id de vaisseau, sa présentation (roleplay) et donc sa évite pas mal de requêtes pour des données qui ne changement jamais (ou alors si peu souvent)
Maintenant si tu as une meilleure solution... Sa peut être un sujet de réflexion intéressant...
RE: Une grosse table ou plusieurs avec jointures - Anthor - 16-05-2010
Oui oui je te donne une solution au dessus ^^
L'utilité d'un cache ce n'est pas qui modifie, c'est le nombre de fois où tu y accèdes.
En l'état, ça n'a donc strictement aucune utilité, puisque tu n'économises au final rien du tout.
Tu utilises la session pour un seul utilisateur, et quitte à utiliser un fichier, autant que ce soit commun.
Et même le cache de MySQL serait mieux puisqu'il agit sur tout le monde et pas uniquement, pour un utilisateur précis.