Il y a donc deux tables supplémentaires qui fonctionnent avec ces paramétrages.

AL_SITE
AL_PROCEDURE

Chaque entrée de alert_param peut être liée à 0 ou n sites ce qui occasionnent 0 ou n entrées dans le AL_SITE.
Chaque entrée de alert_param peut etre liée à 0 ou n procédures qui occasionnent 0 ou n entrées AL_PROCEDURE

Si un paramétrage est lié à aucun site, il concerne tous les sites
Si un paramétrage est lié à aucune procédure, il concerne toutes les procédures

Dans un contexte donné, on doit tenir compte d'un paramétrage si la procédure du dossier courant est liée à une entrée dans d'alerte_param qui concerne cette procédure
et si le site du dossier courant est lié à une entrée dans alerte_param qui concerne ce site.

Il est vrai que la dernière catégorie de paramétrage que j'ai crée ne travaillera pas avec AL_PROCEDURE.

Cependant, un nouveau type de restriction pourrait voir le jour et être commun à plusieurs catégories de paramétrage.

Pour l'interface de paramétrage d'une catégorie de paramétrage (formulaire avec saisie des relations 1/N, liste & export PDF, critère de recherche, l'export-import entre base de données),
il est très simple de créer un interface de base héritant de l'interface de base en ne montrant que les éléments souhaités

Dans ce cas précis, il m'a semblé préférable de tout regrouper au sein d'une même table.

Pour répondre précisement au post de SQLpro

1) la table a pu vivre sans jusqu'ici...
> oui
2) ces nouvelles colonnes sont elles réellement des attributs propres l'entité que la table modélise ? J'en doute
> selon les catégories de paramétrages
3) que faire des lignes actuelles ? Mettre une valeur par défaut bidon pour éviter le poison des Nulls ou laisser les Nulls afin de gruyériser sciemment la table ?
on laisse null
4) que va t-il se passer si certains programmes utilisant cette table font des SELECT * pour afficher les données de ladite table ?
> Aucun select *, on va chercher des éléments précis selon certains critères dont ceux énoncés plus haut
5) a votre avis la rapidité des requêtes utilisant actuellement cette table dans les programmes existant, sera t-elle améliorée par cet apport de colonnes qui ne sera probablement jamais utilisé ?
> Ce sont des tables de paramétrages avec peu d'entrées en général moins de 100 entrées
6) pour couronner le tout, les nouvelles données, lors des mises à jour, vont bloquer l'accès à la table de manière exclusive ce qui empêchera de lire les autres données et toutes les requêtes tapant dans cette table s'en trouveront donc ralenties....
> Ce sont des tables de paramétrages très rarement mis à jour