Conception d'une base : une grosse table ou plusieurs petites?

bobymaw · 10/07/2011, 11h17

Bonjour
Après avoir lu l'article :*http://blog.developpez.com/sqlpro/p1...ances-petites/

Je me pose la question : est-il plus utile d'avoir une table d'une 60 aines de champs.
Ou de la scinder en deux tables de 40 et 20*champs?
Une fois les tables créées et les insertions faites, la première partie ne devrait subir presque que des recherches. Alors que la deuxième (l'éventuelle table de 20 champs) sera amenée à être souvent modifiée.
Les recherches porteront simultanément sur les deux tables.

Sachant que la base devrait contenir entre 500 et 3000 tuples.

MaitrePylos · 11/07/2011, 11h11

Si je devais te donner un conseil, cela serait de relire et de comprendre l'article que tu mets en référence.

Le nombres de champs que tu mets dans les tables n'ont pas une grande importance, c'est la façon dont tu modélises les tables et la façon dont tu normalises les données.

Il faut au minimum aller jusqu'à la troisième forme normale (personnellement et ce n'est que mon avis, c'est souvent suffisant).

A partir de là tu verras si il te faut une,deux,trois ou plus de tables.

estofilo · 11/07/2011, 14h40

Une chose à savoir sur postgres est que quand une ligne subit un UPDATE, en principe toute la ligne est physiquement copiée vers un nouvel emplacement. Plus tard l'emplacement de l'ancienne version de la ligne est récupéré par un processus dénommé vacuum qui s'exécute plus ou moins en tâche de fond. Cette manière de faire sert à permettre les visibilités différentes de chaque transaction sur les données.

Pour cette raison là, scinder une table en deux en séparant les colonnes fréquemment mises à jour des colonnes jamais mises à jour est en effet une optimisation. Ça va faire moins de travail au moment de l'update, moins de fragmentation dans les données, moins de travail pour vacuum.

Mais encore faut-il que les volumes et/ou la fréquence de mise à jour le justifient. Si on parle de quelques updates/jour répartis sur 3000 lignes, en pratique cette optimisation sera inutile. En revanche si c'est quelques centaines de milliers d'update par jour ou plus, là ça a des chances d'être utile.

10/07/2011, 11h17	#1
bobymaw Candidat au titre de Membre du Club Inscription : juillet 2003 Messages : 51 Détails du profil Informations forums : Inscription : juillet 2003 Messages : 51 Points : 10 Points : 10	Conception d'une base : une grosse table ou plusieurs petites? Bonjour Après avoir lu l'article :http://blog.developpez.com/sqlpro/p1...ances-petites/ Je me pose la question : est-il plus utile d'avoir une table d'une 60 aines de champs. Ou de la scinder en deux tables de 40 et 20champs? Une fois les tables créées et les insertions faites, la première partie ne devrait subir presque que des recherches. Alors que la deuxième (l'éventuelle table de 20 champs) sera amenée à être souvent modifiée. Les recherches porteront simultanément sur les deux tables. Sachant que la base devrait contenir entre 500 et 3000 tuples.
	00

11/07/2011, 11h11	#2
MaitrePylos Rédacteur/Modérateur Gérard Ernaelsten DBA & Dev PHP Inscription : juin 2005 Messages : 3 174 Détails du profil Informations personnelles : Nom : Gérard Ernaelsten Âge : 39 Localisation : Belgique Informations professionnelles : Activité : DBA & Dev PHP Secteur : Service public Informations forums : Inscription : juin 2005 Messages : 3 174 Points : 6 460 Points : 6 460	Si je devais te donner un conseil, cela serait de relire et de comprendre l'article que tu mets en référence. Le nombres de champs que tu mets dans les tables n'ont pas une grande importance, c'est la façon dont tu modélises les tables et la façon dont tu normalises les données. Il faut au minimum aller jusqu'à la troisième forme normale (personnellement et ce n'est que mon avis, c'est souvent suffisant). A partir de là tu verras si il te faut une,deux,trois ou plus de tables. __________________ Il faut toujours viser la lune, car même en cas d'échec on arrive dans les étoiles. O.Wilde Mes Articles/Critiques : Merise - Guide pratique PHPExcel PostgreSQL : Administration et exploitation d'une base de données PostgreSQL : Entraînez-vous à créer et programmer une base de données relationnelle
	10

11/07/2011, 14h40	#3
estofilo Modérateur Inscription : octobre 2008 Messages : 1 508 Détails du profil Informations personnelles : Localisation : France, Paris (Île de France) Informations forums : Inscription : octobre 2008 Messages : 1 508 Points : 2 040 Points : 2 040	Une chose à savoir sur postgres est que quand une ligne subit un UPDATE, en principe toute la ligne est physiquement copiée vers un nouvel emplacement. Plus tard l'emplacement de l'ancienne version de la ligne est récupéré par un processus dénommé vacuum qui s'exécute plus ou moins en tâche de fond. Cette manière de faire sert à permettre les visibilités différentes de chaque transaction sur les données. Pour cette raison là, scinder une table en deux en séparant les colonnes fréquemment mises à jour des colonnes jamais mises à jour est en effet une optimisation. Ça va faire moins de travail au moment de l'update, moins de fragmentation dans les données, moins de travail pour vacuum. Mais encore faut-il que les volumes et/ou la fréquence de mise à jour le justifient. Si on parle de quelques updates/jour répartis sur 3000 lignes, en pratique cette optimisation sera inutile. En revanche si c'est quelques centaines de milliers d'update par jour ou plus, là ça a des chances d'être utile.
	10

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email