Discussion :

[UNi[FR]]

Bonjour à tous,

j'ai une petite question concernant la modélisation de table de paramétrage :

Je dois retravailler une base Access pour la passer sur une base MySQL,j'en profite donc pour optimiser le tout.

J'ai plus d'une dizaine de tables avec la même structure :

Code :

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

1
2
#Code
libellé

et je souhait passer le tout sur 2 tables :

Code :

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

1
2
3
4
5
6
7
8
9
Table param_types :
#id_type VARCHAR(255) UNIQUE

Table param_values
#id_param_value AUTOINCREMENT int
id_type VARCHAR(255) 
param_value VARCHAR(255)
param_value_libelle
(id_type + param_value UNIQUE)

qu'en pensez-vous ? est-ce une bonne solution ?

Merci d'avance pour vos retours !

[Richard_35]

Bonjour UNi[FR],

C'est un débat éternel entre les "pro-" et les "anti-".

Personnellement, j'ai toujours préférer autant de tables que de "notions". Souvent, cela n'a eu aucun intérêt et ta solution de regroupement aurait fonctionné.

Parfois, malgré tout, avec le temps, il a fallu enrichir certaines de ces tables avec des propriétés (champs) qui lui sont propres (et pas aux autres). Dans ce cas, il aurait été dommage d'ajouter un champ toujours nul pour les autres tables.

Et que dire des requêtes analysant des données liées à ces tables, en cas de regroupement...

[UNi[FR]]

Merci pour ce retour !

[CinePhil]

Comme Richard, je préfère faire autant de tables de référence que nécessaire. Je ne mélange pas les types avec les départements, les familles avec les villes et les torchons avec les serviettes.

Avoir une seule table de paramètres empêche d'affiner les caractéristiques des colonnes de la table et obligera à faire plusieurs jointures sur la même table de référence pour la plupart des requêtes, ces jointures se faisant sur un nombre utile restreint de lignes.

Je n'y vois que des désavantages.

Le cas où cela semble plus adapté, c'est celui des caractéristiques variées des familles de produits, quand on a beaucoup de ces familles. Il n'est alors pas forcément très pratique d'avoir autant de tables que de familles par héritage de données et la table des caractéristiques semblent plus appropriée mais personnellement je n'ai jamais eu à y recourir.