Avoir une infinité de tables ou une infinité d'entrée??

**cdt2u** · 22/01/2005, 09h14

Bonjour,

Il y a une question que je me pose depuis un petit moment au sujet des tables avec MySQL.
J'ai lu le FAQ, mais je n'ai pas trouvé la réponse. "Est-ce qu'il vaut mieux plusieurs petites tables ou une grosse ?" semblait y répondre mais en fait il parle du nombre de colonne et pas du nombre d'entrées...

Donc voilà mon problème:
J'ai créé un programme gratuit pour créer des jeux (QCM) en PHP/MySQL, chacun peut s'inscrire et créer un nouveau jeu.

A chaque fois qu'un nouveau jeu est créé, 4 tables sont automatiquement créées propres au jeu. Chaque jeu a donc 4 tables de même schéma (ex: Joueurs, Jeu, Questions, Records).

Exemple:

Pour le JEU n°1, les tables sont:
1_JOUEURS
1_JEU
1_QUESTION
1_RECORD

Pour le JEU n°2, les tables sont:
2_JOUEURS
2_JEU
2_QUESTION
2_RECORD

...

Chaque groupe de table (joueurs, jeu, question, record) correspondant à un jeu est indépendant d'un groupe de table correspondant à un autre jeu. Il n'y a donc pas de problème de jointure entre chaque jeu qui pourrait ralentir les performances.

Jusque là tout va bien. Le problème c'est que mon programme a eu un tel succès que j'ai maintenant plus de 600 jeux. Ce qui me fait plus de 2700 tables dans ma base de données!!! J'avais opté pour cette solution parce qu'elle plus facile à gérer vu que chaque jeu à ses propres tables, on les repère tout de suite.
Ca n'a pas l'air de ralentir les jeux pour autant. Pour l'instant l'ensemble de la base de donnée fait seulement 2 MO.

Je voudrais donc savoir ce qui est mieux:

1) Avoir un nombre infini de tables de mêmes schémas avec un nombre d'entrées limitées

Exemple:

1_JOUEURS: 5 entrées
1_JEU: 15 entrées
1_QUESTION: 30 entrées
1_RECORD : 50 entrées

2_JOUEURS : 2 entrées
2_JEU: 6 entrées
2_QUESTION: 50 entrées
2_RECORD: 10 entrées

... etc ... et ce pour un total de 2700 tables actuellement

OU

2) Avoir juste 4 tables de même schéma avec un nombre infini d'entrées (et dans ce cas, il y aurait une colonne supplémentaire pour identifier à quel jeu appartient chaque ligne de donnée)

Exemple:

JOUEURS: 500 entrées
JEU: 150000 entrées
QUESTION: 3000000 entrées
RECORD : 500000 entrées

... et encore je pense que j'ai sous-estimé le nombre d'entrées dans cette deuxième solution...

Qu'est-ce qui est le plus rapide? Qu'est-ce qui est le plus optimal?
Je voudrais que mes jeux se chargent le plus rapidement possible.
Merci d'avance pour vos réponses!

Mon hébergeur: Free.fr et bientôt Online.net
Version MySQL: 4.0.22

**Celelibi** · 22/01/2005, 17h20

en ce qui me concerne je pense que le nombre de table ne devrait pas être variable, si les tables sont générés automatiquement c'est qu'elle ont sûrement des schémas proches, donc je mets tout dans une seul table avec une colone d'identification.

dans ton cas ça donnerai tes 4 tables qui existent déjà avec une colone id_jeu, + une table qui regroupe tous les jeux.

par contre niveau performances je ne sais pas du tout ce que ça vaut.
le temps d'accès aux lignes désirés risque d'être ralongés, mais tu n'aura plus que 5 tables. de plus tu aura des jointures légèrement plus complexes et une condition en plus (le jeu désiré).
ça te permettrait aussi de faire des statistiques sur tous les jeux que tu aurais peut-être eut du mal à faire avant.

à mon avis si tu multiplie les tables ça ira plus vite, mais si tu as seulement 5 tables tu pourras faire plus de choses. donc à toi de choisir.

**cdt2u** · 22/01/2005, 23h00

si les tables sont générés automatiquement c'est qu'elle ont sûrement des schémas proches,

Oui c'est le cas, elles ont le même schéma. (ex: la table 1_joueur a le même schéma que la table 2_joueur.) C'est pour ça que j'envisage de les regrouper.

Mais avant de le faire, je voudrais savoir si c'est plus performant.

En d'autres mots, est-ce que MySQL est plus rapide à trouver les tables dans une base, ou est-il plus rapide à trouver les lignes dans une table?

ça te permettrait aussi de faire des statistiques sur tous les jeux que tu aurais peut-être eut du mal à faire avant.

Ca c'est bon, même avec 2700 tables, j'ai réussi à obtenir les statistiques que je voulais.

à mon avis si tu multiplie les tables ça ira plus vite,

Donc d'après toi, si je veux privilégier la rapidité, je devrai garder mon programme tel quel avec une "infinité" de table? Je dis une infinité car il grossit tous les jours!

**Celelibi** · 22/01/2005, 23h41

si tu as vraiment beaucoup de tables c'est le système de fichier qui va finir par te limiter, aussi bien dans le nombre de tables que dans la rapidité.
en effet la plus part des systèmes de fichiers limitent le nombre de fichier par répertoir, et une table MyISAM c'est 3 fichiers.
je ne pense pas que mysql fasse une recherche (à proprement dit) sur les tables, mais se contente de demander le contenu du fichier appellé "machin" à l'OS (à travers une API en générale) donc si il y a plusieurs milliers de fichiers avant de trouver le tien ça risque d'être long.

il faut savoir qu'informatiquement aucune infinité n'est permise (y'a que le cerveau humain pour inventer un tel concepte :p). tu ne peux avoir ni une infinité de fichiers ni un fichier d'une taille infinie.

pour résumer, je pense qu'accéder à un fichier dans un répertoir est plus rapide que de rechercher une ligne dans une table, mais fais attention aux limitations de FS si tu as vraiment beaucoup de tables créés par jour.

**Maximil ian** · 23/01/2005, 18h21

J'ajouterais que conceptuellement la solution de Celelibi (4 tables + 1 table Jeux) me paraît beaucoup plus propre et elle facilite les choses. Par exemple tu pourrais facilement afficher en page d'accueil la liste de tous les jeux classés par thème, alors qu'actuellement je vois mal comment faire à part en ayant recours à d'immondes bidouilles

Maintenant, c'est sûr que les performances ne s'amélioreraient pas, mais si les tables sont correctement indexées ça ne devrait pas trop se faire sentir...