Une seule table Paramètre de type "Code-Libellé" pour toute l'application

Bonjour,

Dans notre société, nous travaillons sur une gestion de contacts.
Nous avons dans cette application plusieurs paramètres (ex : Civilité, Pays, Origine du contact, etc.)
Mon collègue et moi avons un point de divergence sur la modélisation de ces paramètres.
Je souhaiterais créer une table pour chaque paramètre : Les tables Civilite, Pays, OrigineContact seraient liées à la table Contact.
Mon collègue voudrait créer qu'une seule table Paramètre qui regrouperait tous les paramètres de type Code-Libellé dans une seule et même table. Dans cette table, on aurait une colonne TypeParametre qui indiquerait le type de paramètre : 1 = Civilité, 2 = Pays, 3 = Origine du contact.

Les avantages de cette solution sont :
1 - On peut créer autant de paramètres que l'on veut sans toucher à la modélisation de la base (métadonnée).
2 - On peut facilement stocker en mémoire dans l'application tous les paramètres. Ainsi, on ne fait plus d'accès à la base pour charger les paramètres

Les inconvénient de cette solution sont :
1 - Il n'y a pas de lien d'intégrité entre la table Contact et Parametre car une civilité peut être liée à un pays par exemple.
2 - Cela ajoute de la complexité dans la lecture de la base de données et dans les requêtes.


Qu'en pensez-vous ?

J'attends avec impatience vos avis :)

Merci d'avance.

Bonjour Lelebap,


Après 45 ans de modélisation, de construction et de suivi des bases de données en production, après des wagons d’expertises, d’audits, de remise à plat et de réfection de bases de données dans tous les secteurs d’activité, je peux vous assurer que la 1re solution est la bonne, elle est pérenne :

Mettez en œuvre une table PAYS, une table CIVILITE, etc.

J’ai vu des entreprises avoir mis en œuvre la solution "métadonnées" : c’est rapide à mettre en œuvre quand il faut être très réactif, mais c’est un pis-aller, un facteur de complexité, ça incite à la paresse et il faut une discipline de fer pour qu’au fil des ajouts ça ne devienne pas le b...

Bonjour fsmrel,

Merci pour votre réponse.
Quelqu'un d'autre pourrait nous donner son avis ?

Bonjour,

Citation:

---

Envoyé par fsmrel

[...] je peux vous assurer que la 1re solution est la bonne, elle est pérenne :

Mettez en œuvre une table PAYS, une table CIVILITE, etc.[...]

---

Je rejoins entièrement fsmrel sur ce point.

Citation:

---

Envoyé par lelebap

Les inconvénient de cette solution sont :
[...]
2 - Cela ajoute de la complexité dans la lecture de la base de données et dans les requêtes.

---

Pas tant que cela in fine je pense.

;)
Chtulus

De notre côté, nous nous posons la même question.

Je pense qu'il ne faut pas être extrémiste, et laisser un peu de souplesse.

Si je mets en balance les bénéfices/risques, je me dis que je préférerais avoir une table paramètre et me coltiner les quelques désavantages de cette solution, plutôt que 50 petite tables à colonne unique.

Bonjour,

Les qualités essentielles d’un système reposent tout d’abord sur la simplicité de sa maintenance et sur son ouverture permettant de faire évoluer le système en fonction des nouveaux besoins exprimés par les utilisateurs.

L’utilisation des métadonnées simplifie énormément la complexité des bases de données, et permet la gestion des différents paramètres de manières analogues.

Nous avons développé une structure de métadonnées que nous utilisons sur tous les systèmes que nous développons ce qui nous permet de gagner en productivité car nous ne sommes pas amenés à redévelopper du code à chaque fois. Cette approche nous permet également de gérer tous nos systèmes dans différentes langues en garantissant une cohérence complète.

Cette méthode nous permet également une très grande souplesse dans la manière de décrire des éléments avec plus ou moins de paramètres et de faire évoluer leur description dans le temps sans avoir à changer ou ajouter une seule ligne de code.

Cette approche correspond à ce qu’on appelle la « standardisation » d’une base de données, qui est un des principaux critères de qualité dans un modèle de données

Bonjour,

Je suis le collègue de Lelebap.
Cela ne fait que 40 ans que je travaille sur des systèmes informatiques et bases de données (principalement chez Hewlett-Packard)
C'est vrai qu'avant, pour ce type de table il était plutôt conseillé de faire une table par type.
Cela a posé quelques problèmes sur certaines applications car le nombre de tables ouvertes à un instant t était limité.
Maintenant les bases ont bien évolué et ces contraintes ont disparue.
D'autre part le nombre de records, avant était limité ce qui poussait les développeurs à utiliser plusieurs tables.
Ce problème n'existe plus.

Dans le cas qui nous intéresse ou nous allons avoir pas mal de tables avec juste un libellé ou un code et un libellé, il me parait bien plus logique de travailler sur une structure unique.
L'intérêt est de ne développer qu'un module pour gérer ce type de table, pour en construire des combos, des listes etc.
La programmation se fait dans une classe qui gère toutes les requêtes, les contraintes et intégrités.

Après bien sûr on peut se poser la question de gérer des contraintes au niveau de la base.
C'est ce qu'il faut faire en général quand c'est possible et quand la base le permet.
Toutes les bases n'observent pas toutes les normes et la description des contraintes est quelque fois différente d'une base à l'autre ce qui complique la portabilité.

J'en fais, par expérience exception pour ce type de table vu l'intérêt du développement, de la maintenance et de l'évolution de l'application.
Il est souvent utile, ou pratique ou même nécessaire que l'utilisateur final puisse créer ses propres tables dynamiquement.
En procédant avec une table unique les choses deviennent possibles sans avoir à demander un développement et une mise à jour de la structure de la base.

Cela présente aussi quelques avantages au niveau des traductions éventuelles à faire.
Bien sur le fichier base est moins "lisible" puisque toutes les "tables logiques" sont dans une "table physique".
Mais je ne vois pas l'intérêt d'avoir une lisibilité de ce type de table.

Comme toujours, respecter des normes, des principes etc. c'est parfait mais il arrive aussi que le mieux soit l'ennemi du bien.
D'ailleurs la meilleure preuve est le fonctionnement interne d'une base et de la structure des définitions de fichier et rubriques. Ce sont quasi systématiquement des métas schémas qui profilent les schémas de la base.

Depuis que je développe des applications je n'ai jamais eu de problème d'intégrité ou quoique ce soit en utilisant évidemment et obligatoirement les classes qui vont bien.



Et pour en revenir à Einstein il disait fort justement :
La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi.

Bonjour denisdlu,

Bonnes explications ;)

Voici par exemple un article d'SQLpro sur les Méta Données.
Si cela peut vous aider/réconforter sur votre approche.

Cordialement,
Chtulus

Bonjour Chtulus,

Oui merci pour le lien .
En fait le but était plus de convaincre mon collègue que de trouver une solution.
Il y a bien longtemps que je travaille avec ce genre de table et je suis convaincu que c'est une bonne solution .

Il est vrai que dans ces posts il a été mentionné improprement le terme métadonnées( et/ou méta-schémas )
Disons que pour ces tables simples ( code , ou code et libellé , voir un peu plus) on utilise un peu le même principe finalement.

Si on voulait simplifier à l'extrême c'est vrai qu'on pourrait utiliser une "méta-base" avec seulement quelques fichiers pour définir tous les cas possibles ( table fichier , table rubrique , table data , et quelques tables pour définir les contraintes etc)
Mais cela rendrait les requêtes bien plus lourdes et complexes à mettre en œuvre.
S'amuser à faire cela est un excellent exercice pour définir n'importe quelle base aussi complexe soit-elle.

Cela remonte à longtemps mais je pense que quand j'avais adopté le principe d'une table pour gérer toutes les petites tables j'avais du m'inspirer des méta-schémas.

En tout cas cette manière de travailler même si elle ne semble pas 100% académique , résous pas mal de problèmes , limite les développements fastidieux tout en soulageant la maintenance.

Cordialement.
denis