Une grosse table ou plusieurs avec jointures

[php_addict]

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)

[Allwise]

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

[php_addict]

Quand tu dis beaucoup d'enregistrements tu penses à combien ? milliers, centaines de milliers, millions, dizaines de millions ?

300.000 ou 400.00 maxi...

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

[Argorate]

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.

[atra27]

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

} 

[Anthor]

Quitte à utiliser les sessions, autant faire une classe qui utilise un fichier, et est disponible pour tous. ^^

[atra27]

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...

[Anthor]

Quel que soit l'utilité, faire un cache session pour ça n'a aucune utilité ^^

[atra27]

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...

[Anthor]

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.