Section courante

A propos

Section administrative du site

Agrégation de table : Toutes les relations étrangères dans la même table versus une table pour chacune des relations ?

Lorsqu'on veut développer une base de données avec beaucoup de contenu et obtenir une certaine efficacité dans ses résultats, une question finit par se poser, doit-on mettre toutes les relations étrangères dans la même table ou une table pour chacune des relations ?

Ainsi, prenons pour exemple, les deux tables suivantes :

Table A - Entité primaire avec méta
Table B - Relation
  1. Primary ID de Table A
  2. Key (Couleur, Emplacement, Pays,...)
  3. Primary ID de Table A
  4. Key (Couleur, Emplacement, Pays,...)

On pourra à l'aide de deux tables, regrouper les informations d'objet, tel que :

Et tout ceci sera regroupé dans deux tables plutôt que des dizaines, voire des centaines de tables différentes. D'ordinaire, on utilise cette stratégie d'agrégation de table pour les entrepôts de données, mais des produits comme WordPress par exemple cette stratégie par exemple, tandis que des CMS comme Drupal préfèrent les séparer dans différentes tables. Suivant cette idée, l'un aura peu de tables tandis que de l'autre en aura beaucoup. Voici le schéma des deux approches différentes, en prenant pour exemple le CMS de WordPress versus Drupal, on voit une nette différences entre les deux :

WordPress Drupal

Comparatif

Voici une comparaison des différentes stratégies :

4 clefs étrangères / une table de relation 2 clefs étrangères / multiple table
Le nombre de jointures est plus simple, mais parfois récursif Le nombre de jointures à tendance a augmenté considérablement plus le système à des besoins complexes.
Il est facile de mémoriser le nom de toutes les tables pour un humain Les tables deviennent trop nombreuses pour être mémorisées par un humain.
Une redondance de la même information peut se produire plus souvent La redondance est moins fréquente
Meilleure recycle des structures existantes Chaque nouvelle structure doit être recréée de nouveau.
Permet la création dynamique de composante, ainsi, un plugiciel de logiciel n'aura pas besoin de créer de nouvel table pour s'intégrer à un produit. Les composantes sont statiques, l'ajout d'un plugiciel de logiciel nécessite régulièrement l'ajout de nouvelles tables dans le produit.
L'identificateur est unique pour toute la base de données Il peut y avoir le même identificateur pour différentes tables et donc les identificateurs ne peuvent être uniques à travers toute la table.
Réduction des entrées/sorties, des calculs du microprocesseur et des exigences d'échange de données On doit consulter plusieurs tables différentes pour obtenir un résultat
Réduis le nombre d'enregistrements devant être lu L'information est souvent située dans de nombreux enregistrements différents.

Produit

Voici des exemples de produits en fonctions des stratégies :

Catégorie 4 clefs étrangères / une table de relation 2 clefs étrangères / multiple table
CMS WordPress, Nstein (WCM),... Drupal, Liferay,...
CRM   vTigerCRM


Dernière mise à jour : Samedi, le 3 juin 2017