Mieux vaut une grosse table ou plein de petite ?

**ShinJava** · 15/11/2005, 09h40

Bonjour tout le monde,
J'espere que vous allez tous bien

Alors il est vrai que ma question aurait pu être poser sous un autre forum mais comme pour le moment je suis dans une logique PHP/MySQL et j'imagine que beaucoup d'entre vous ont du faire face à ce probleme, voici ma question :

Quand une table deviens trop grosse est-il preferable de la découper en plusieurs petites tables ? J'imagine que oui mais j'aimerais qu'on prenne un exemple concret !

Je pense que vous connaissez tous le grand site d'enchère qui commence par "E" et qui fini par "bay".
Ils ont enormement d'utilisateur, pensez vous que chaque utilisateur à sa propre table dans la BDD (base de donnée) ?
A chaque utilisateur est attribué des commentaires (positif, neutre, négatif) : ces commentaires sont aussi stockés dans une table différente pour chaque utilisateur ?

Personnelement j'avais penser à ce que les tables soit découper par ordre alphabétique (une table pour les utilisateur A etc...), ou bien par Pays ? Mais au niveau des commentaires !?

Ca serait une table de type :
IDUtilisateur / Commentaire (dans ce cas la c'est le gros bordel avec un grand nbre d'utilisateur comme le site d'enchere en question)

Ou bien une table_commentaire par utilisateur ? (ca ferait beaucoup de table!)

Rah voila à quoi je pense en ce moment, j'aimerais avoir vos avis dessus, ca se trouve jsuis passé à côté de quelque chose ! ?

Merci d'avance !
++
ShinJava

**ankou2005** · 15/11/2005, 09h52

Bonjour,

Je pense pas que la solution d'avoir une table par utilisateur soit la bonne approche.
Car ca voudrait dire 100 tables pour 100 utilisateurs docn pas facile à gérer.

Personnellement, je ferais une table utilsateurs et une table commentaires liées par l'ID de l'utilisateur. (avec des index pour améliorer la lecture)

Ca serait une table de type :
IDUtilisateur / Commentaire (dans ce cas la c'est le gros bordel avec un grand nbre d'utilisateur comme le site d'enchere en question)

Je pense au contraire que c'est moins le bordel à gérer que de gérer des multitudes de tables.

Apres je ne connais pas tes besoins ni tes connaissances, mais je pense que la solution la plus simple à gérer pour ton exemple c'est une table utilisateur et une pour les commentaires.

Ce n'est que mon avis.

Ankou

**nako** · 15/11/2005, 09h52

Salut, alors en effet, c'est pas trop du PHP, mais plutôt de la conception de Base de données.

Je connais pas exactement le fonctionnement de i-baie, mais j'imagine qu'un utilisateur peut avoir plusieurs commentaires.
De manière générale, dans ta table utilisateur, tu mettras les infos propres à l'utilisateur. Dans le cas de commentaires, qui sont multivalués, tu passeras par une autre table liée.

Exemple :

Utilisateur(ID, nom, prenom, login, motdepasse, adresse)
CommentaireUtilisateur(IDUtilisateur, Commentaire, DateCommentaire)

J'espère que j'ai plus ou moins répondu à ta question.
a+

[edit]
grillé !
PS : regarde les notions de bases de données, notamment les formes normales, ça pourra t'aider

**ShinJava** · 15/11/2005, 17h08

Merci pour vos réponses.
Bien sur pour le moment mes besoins ne sont pas si grands que ca, c'est juste que je me demandais comment jprocederais si j'étais face a une telle situation, si il etait de mieux de faire un decoupage d'une enorme table en une centaine table ou pas...
Enfin bref ! merci pour vos reponses !

++
ShinJava

**zulot** · 15/11/2005, 17h14

je crois qu'avec php tu dois pouvoir lire et ecrire sur du fichier texte.

donc moi je penche plus dansle cas de gros site comme ca pour un fichier texte utilisateur avec 1seule ligne dans la base qui dit ou se trouve se fichier.

mais bon ce n'est que mon humble avis.

**trattos** · 15/11/2005, 17h26

Il vaut mieux plusieurs petite table qu'une grosse!
Exemple une table regroupant des commentaires pour des articles, des dossiers, des fiches. Et bien il vaudrait mieux faire une table commentaires pour chacun!
Sinon pour le reste c'est uen question de ressource, si le matos suit alors y'aura aucun problême et je pense que les bases de données d'Ebay ont un très bon matos lol!

**ShinJava** · 28/11/2005, 09h29

Re tout le monde,
désolé d'avoir mis plusieurs jour pour repondre à ce sujet.

Zulot, effectivement ce que tu dis est plutot interessant, je n'y avais pas pensé, ca risque de faire beaucoup de fichier texte un moment :/ ?

Trattos oui je pense aussi que c'est la meilleur solution.

Mais voila maintenant, je pose la question à tout le monde en general si on prend un exemple concret comme le site de rue-montgallet.
Ils repertorient aux moins une 30aine de boutique dont chacun ont en moyenne 500 articles et 300 avis (c'est une moyenne presque fictif).
Donc ici j'imagine que :
Chaque boutique à sa propre table de commentaire et sa propre table des arcticles en vente ?

Ensuite chaque article à aussi des commentaires (imaginons que la moyenne serait de 1000 commentaires par articles),
Est-ce que dans ce cas la, chaque articles aurait sa propre table de commentaire ? (c'est à dire 15.000 Tables ! ? (500 articles * 30 boutiques) )

Merci d'avance pour vos eclaircissement.

++
ShinJava

Invité · 28/11/2005, 09h36

Une table = un handler de fichier.
Le nombre de handlers n'est pas (forcément?) infini suivant les systèmes d'exploitation.
De plus, je pense, sans pouvoir le prouver, qu'une grosse table permettra d'utiliser mieux le système de cache de mysql (et celui du serveur) qu'une floppée de petites tables.

Je me demande si cette question n'est pas récurrente et déjà traitée ailleurs

.

**Mr N.** · 28/11/2005, 09h40

Non non non et non !
Il ne faut pas "plusieurs petites qu'une grosse" (ma femme confirme)
Ca ne veut rien dire quand c'est sorti du contexte.
Un modele parmis tant d'autres possibles pour ton exemple ShinJava :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
BOUTIQUE(id, nom, adr,...)
ARTICLE(id, nom, description, ...)
ARTICLE_BOUTIQUE(id_article, id_boutique, ref, stock, ...)
AVIS(id, auteur, commentaire, note,...)
AVIS_BOUTIQUE(id_avis, id_boutique)
AVIS_PRODUIT(id_avis, id_boutique)
...

**siddh** · 28/11/2005, 09h46

Envoyé par Mr N.

(ma femme confirme)

failli pas le voir

sinon pour ses histoires de tables,
il me semble qu'il vaut mieux stocker les infos de meme natures au meme endroit.
Une base de données est par principe faite pour stocker beaucoup d'infos et meme si mysql n'est pas oracle, ca reste une base tres performante.

Garde un vrai model relationnel plutot que d'avoir 3000000 tables ou tu t'y retrouveras pas

**ShinJava** · 28/11/2005, 15h07

Alors tout d'abord merci à vous 3 ! Suite à vos réponses j'ai fais quelques recherches et j'ai les idées beaucoup plus claires !
Donc en gros MySQL est assez performant pour supporter d'enormes tables.

J'aimerais reprendre le modèle de Mr N. en y ajoutant les nombres de lignes entrée (selon les données estimées plus haut) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
BOUTIQUE (id, nom, adr,...)                                  // 30 lignes
ARTICLE (id, nom, description, ...)                          // 15000 lignes (500 articles x 30 boutiques)
 
ARTICLE_BOUTIQUE (id_article, id_boutique, ref, stock, ...)  // 15000 lignes
 
AVIS (id, auteur, commentaire, note,...)                     // 509000 lignes ((30 boutiques x 300 avis) + (500 articles x 1000 avis))
 
AVIS_BOUTIQUE (id_avis, id_boutique)                         // 9000 lignes (30 boutiques x 300 avis)
 
AVIS_PRODUIT (id_avis, id_produit)                           // 500000 lignes (500 articles x 1000 avis)

Bien sur je suis tout à fait conscient que les requetes sont faites selon plusieurs critères et limites, ca serait du suicide de faire un Select * From AVIS_Produit sans limite et mot clé !

Donc une dernière question et j'arrete de vous embeter : une table MySQL peut supporter plusieurs Millions de lignes ? (j'imagine qu'il y a tjs moyen de decouper en sous categorie ensuite si on attend des chiffres faramineux).

Merci d'avance
++
ShinJava

**siddh** · 28/11/2005, 15h12

tout depend de ta version de mysql et du type de tables.

Si tu prend une version 4.1 mini avec des tables en innodb ca doit etre jouable.

Mais apres faut un bon serveur avec des disques performants aussi.

http://dev.mysql.com/doc/refman/5.0/...enchmarks.html

**Mr N.** · 28/11/2005, 15h30

Envoyé par ShinJava

J'aimerais reprendre le modèle de Mr N. en y ajoutant les nombres de lignes entrée (selon les données estimées plus haut) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
BOUTIQUE (id, nom, adr,...)                                  // 30 lignes
ARTICLE (id, nom, description, ...)                          // 15000 lignes (500 articles x 30 boutiques)
 
ARTICLE_BOUTIQUE (id_article, id_boutique, ref, stock, ...)  // 15000 lignes
...

Pas exactement

En fait j'étais parti du principe qu'un article (ou produit) pouvait être dans x boutiques.
Par exemple, un pack de lait candia se trouve chez Carrouf, Auchan et Géant, mais pas chez 8à8
Ainsi j'aurais une seule ligne "Pack de lait Candia" dans la table article,
et 3 lignes dans la table article_boutique, 1 pour chaque magasins.
Ca correspond à mon modèle mental, après tout dépend de l'application, des besoins, ...
Donc suivant tes chiffres, ca donne plutot :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
BOUTIQUE (id, nom, adr,...)                                  // 30 lignes
ARTICLE (id, nom, description, ...)                          // 500 articles
 
ARTICLE_BOUTIQUE (id_article, id_boutique, ref, stock, ...)  // 15000 lignes
 
AVIS (id, auteur, commentaire, note,...)                     // 509000 lignes ((30 boutiques x 300 avis) + (500 articles x 1000 avis))
 
AVIS_BOUTIQUE (id_avis, id_boutique)                         // 9000 lignes (30 boutiques x 300 avis)
 
AVIS_PRODUIT (id_avis, id_produit)                           // 500000 lignes (500 articles x 1000 avis)

Sinon mysql peut avoir des milions de lignes, ce qui importe c'est ta manière de gérer les tables (index aux bons endroits, analyse table fréquents, requetes propre et optimisées, ...)
Et comme le dit siddh, le matériel joue pas mal.

Tu peux aussi te faire un serveur MySQL maître (ecriture) + n serveurs esclaves (lecture) mais là ca commence à devenir chaud à gérer

**thanathz** · 28/11/2005, 15h43

Moi je dis...

Mieux vaut une grosse table bien construite que plein de petite mals foutues

Je vais prendre mon site comme exemple. Derrière, il y a une base qui contient une quarantaine de tables dont quelques unes qui commencent à causer (plus de 9000 joueurs, 46 000 résultats de matchs, 30 000 lignes de stats cumulées et 175 000 enregistrements pour les boxscores

Ce qui est important dans ce genre de BDD, c'est de bien la traiter au départ et de se poser la question du nombre d'enregistrements qu'on va avoir.
Ensuite pour chaque champ, il faut se poser la question de l'optimisation (un BOOL, un TINYINT, SMALINT, INT, BIGINT...) UNSIGNED ou SIGNED.
Il faut aussi à penser à mettre des index (à bon escient) cela permet un tri plus efficace!

Et si on prend bien le temps de concevoir la BDD, laors elle peut grossir, il n'y a pas de problème. Reste aussi à savoir la taille finale qu'aura cette base. CAr MySQL est efficace mais il en existe d'autres qui seront peut-être plus adaptées à tes besoins (Interbase ou ORacle si tu es riche!)

**ShinJava** · 30/11/2005, 09h40

siddh : oki doki, c'est vrai que le matos est un facteur important pour les grosses productions. Merci pour ton les liens sur les benchmarks, ca va m'être utile !

Mr N. : Effectivement ton modèle est plus approprié pour ce type d'application. Et l'histoire d'un serveur MySQL maître et esclaves m'interesse grandement, jvais aller y jetter un ptit coup d'oeil

thanathz : non je suis pas riche T.T , mais oracle n'est pas devenu gratuit recemment ? Et effectivement en ce moment je prend le temps de bien concevoir ma BDD, d'ou mes questions sur le FOFO =) Car je veux pas avoir de pb si jamais elle prenais un peu de poids... Mais bon si une table MySQL peut accepter des Millions d'enregistrement, tout devrait bien aller hehe.

Bah merci encore à tout ceux qui ont participés à ce sujet, j'ai les idées beaucoup plus claires !

++
ShinJava

**Mr N.** · 30/11/2005, 10h09

Envoyé par ShinJava

Et l'histoire d'un serveur MySQL maître et esclaves m'interesse grandement, jvais aller y jetter un ptit coup d'oeil

Ben je te souhaite bon courage

Pour te faire une idée du bazar :

Un serveur pour le load balancing (repartition uniforme de la charge des différents serveurs)
un serveur mysql esclave, seulement pour la lecture, pour chaque serveur apache/php
un serveur mysql maître dédié à l'écriture... (sur le dessin le serveur maitre se trouve sur le serveur A, surement par soucis d'économie ^^, je l'aurais personnelement mis sur un serveur physique dédié)

J'avais un papier qui expliquait tout ça en détail mais je l'ai pas mis en favoris et je le trouve plus

http://www.ludicorp.com/flickr/zend-talk.ppt