Discussion :

[rokin-k]

Bonjour,

Je n'ai pas beaucoup d'expérience dans le développement de "A à Z" d'un "gros" site dynamique, Jusqu'à présent je touché principalement à de petits sites en Joomla, Vbulletin...
Je vais essayer d'expliquer au mieux mais je ne connais pas grand chose au niveau des termes utilisés pour parler d'une base sql
Actuellement, je me suis lancer dans un site perso qui contiendra plusieurs dizaines de milliers de données dans la base mysql au lancement de celui-ci

les "grosses données" seront répartis principalement en 3 tables :

- Table 1 :
21 champs (chiffres et texte)
~50000 entrées au lancement du site
puis évolution progressive jusqu'au delà de 100000 entrées.
le contenu sera énormément mis à jour et consulté

- Table 2 :
8 champs (chiffres et texte)
~50000 entrées au lancement du site
puis évolution progressive mais cela ne dépassera pas les 100000 entrées rapidement.
le contenu sera peut mis à jour mais beaucoup consulté

- Table 3 :
22 champs (chiffres)
il y aura exactement autant d'entrée que dans la table 1
bref je fait un rapprochement des données entre la table 1 et 3 via un id unique
le contenu sera énormément mis à jour et consulté



et enfin approximativement chaque trimestre je ferais une copie de la structure de la table 3 vers une nouvelle table afin de partir sur les nouvelles données du trimestre (je veut garder les précédentes et celles-ci seront toujours accessibles)



Vaut t'il mieux une table de 100000 entrées ou deux de 50000 entrées sachant que dans mon contenu il y aura "USA" et "EU" en gros (donc facilement divisible en deux)
De même dans la mesures ou toutes les données sont énormément consulté et mises à jours vaux t'il mieux une table de 40 champs ou deux de 20 champs ?
Je n'ai absolument aucunes notions de l'impact qu'aura le volume de données final au niveau des performance du site et tant qu'a etre en plein le nez dedans je préfèrerais essayer de partir dans une structure pas trop dégeux...


merci beaucoup d'avance !!!!

[CinePhil]

D'abord, quoi qu'en dise phpMyAdmin, une table SQL est composée de colonnes et de lignes, pas de champs !

Ensuite, sans nous donner les règles de gestion qui t'ont conduit à structurer la BDD en 3 tables, sans préciser l'univers du discours (de quelles données il s'agit), sans donner le nom des tables ni des colonnes, il sera bien difficile de te dire si tu es sur la bonne voie ou non.

21 ou 22 colonnes pour une table, ça commence à faire un peu beaucoup. Mais ce n'est qu'un a priori puisque je manque d'info pour en juger de manière plus appropriée.

il y aura exactement autant d'entrée que dans la table 1

Je m'interroge aussi sur cette étrange similitude !

et enfin approximativement chaque trimestre je ferais une copie de la structure de la table 3 vers une nouvelle table afin de partir sur les nouvelles données du trimestre (je veut garder les précédentes et celles-ci seront toujours accessibles)

Ce qui veut dire que de trimestre en trimestre, tu auras de plus en plus de tables ayant la même structure ?
Là encore, je doute un peu de l'efficacité d'une telle démarche et je m'interroge sur sa raison.

Vaut t'il mieux une table de 100000 entrées ou deux de 50000 entrées sachant que dans mon contenu il y aura "USA" et "EU" en gros (donc facilement divisible en deux)

Ca veut dire qu'il y aura les mêmes données ; une fois pour USA et une fois pour EU ?
Si c'est le cas, c'est carrément une erreur de conception.

Dis-nous en un peu plus sur les données que tu veux gérer et nous t'aideront à construire ta BDD correctement.

Tu peux déjà consulter le tuto de modélisation Merise pour commencer ton MCD.