Design pattern de gestion de paramètres

Version imprimable

16/02/2016, 09h25
NoPr0n

Design pattern de gestion de paramètres

Bonjour à tous :)

Je viens vers vous car j'aimerais quelques conseils.
Existe t'il des design patterns ou de bonnes pratiques pour la conception d'une ou plusieurs table de gestion des parametrages d'une application ? Les valeurs par défaut, des options d'affichages, ce genre de choses...
J'ai un petit peu cherché mais je n'ai rien trouvé de très probant. Peut-etre que je n'utilise tout simplement pas les bon termes dans ma recherche ...

Merci d'avance pour votre aide :)
16/02/2016, 10h20
SQLpro
C'est juste une problématique de modélisation; Les "design patterns" n'existent pas comme concept de modélisation de bases de données relationnelles...

Mais le modèle à envisager dépend si les paramètres sont strictement applicatifs ou dépendent d'autres informations, comme par exemple l'utilisateur.

Exemples :
- paramètre de date d'installation ou de version de l'application => paramètre applicatif
- paramètre régionaux pour l'affichage des dates => dépend de l'utilisateur
A +
16/02/2016, 10h35
escartefigue

Bonjour,

Pour ce qui est du nommage de vos tables il y a des normes qui sont les suivantes :
- N'utiliser que les 26 lettres de l'alphabet en majuscule et sans caractère diacritique (accent, cédille etc...) + les 10 chiffres de 0 à 9 + l'underscore (touche 8 du clavier)
- Ne pas utiliser de mot réservé SQL (select, date, order, ....)
- Ne pas dépasser 128 caractères

Pour ce qui est des valeurs par défaut, c'est dépendant de l'application, donc pas de règle globale

Pour ce qui concerne les options d'affichage, ce n'est pas du ressort du SGBD ni du SQL, mais de la couche présentation donc de l'application
16/02/2016, 10h54
NoPr0n
Citation:
Envoyé par SQLpro

C'est juste une problématique de modélisation; Les "design patterns" n'existent pas comme concept de modélisation de bases de données relationnelles...

Mais le modèle à envisager dépend si les paramètres sont strictement applicatifs ou dépendent d'autres informations, comme par exemple l'utilisateur.

Exemples :

paramètre de date d'installation ou de version de l'application => paramètre applicatif
paramètre régionaux pour l'affichage des dates => dépend de l'utilisateur

A +
Oui, je m'exprime probablement mal en parlant de Design Pattern. Je parle simplement de "bonnes pratiques" en terme de modélisation.
Ces paramètres ne sont pas du tout dépendant de l'utilisateur. Ce sont des paramètres à 100% applicatif.

Actuellement, je n'ai que quelques paramètres et je me contente d'une table qui ne contient qu'un seul enregistrement et dont chaque colonne correspond à l'une des valeurs. Je me doute que ce n'est pas l'idée et j'aimerais améliorer ça avant d'avoir besoin d'ajouter d'autres paramètres.
16/02/2016, 11h37
escartefigue

Citation:

Envoyé par NoPr0n

Actuellement, je n'ai que quelques paramètres et je me contente d'une table qui ne contient qu'un seul enregistrement et dont chaque colonne correspond à l'une des valeurs. Je me doute que ce n'est pas l'idée et j'aimerais améliorer ça avant d'avoir besoin d'ajouter d'autres paramètres.

Si vous avez peu de paramètres, vous n'aurez pas de table dite "obèse", mais il faut tout de même découper à minima par application, car il ne faut pas que la mise à jour d'un paramètre comptable par exemple gène l'application de gestion commerciale ou inversement.
Le plus souvent, les tables de paramètres sont paramétrées avec des verrous de niveau ligne (row) plutôt que page afin de limiter les attentes au sein d'une même application

Un exemple de table de paramétrage applicatif :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE T_PARAM_PRM
(PRM_ID            INT IDENTITY PRIMARY KEY,
 PRM_NAME          VARCHAR(256) NOT NULL UNIQUE,
 PRM_VALUE         SQL_VARIANT NOT NULL,
 PRM_TYPE          VARCHAR(32) NOT NULL 
                   CHECK (PRM_TYPE IN ('INT', 
                                       'SMALLINT', 
                                       'BIGINT', 
                                       'UNIQUEIDENTIFIER', 
                                       'DATE', 
                                       'TIME',
                                       'BIT',
                                       'FLOAT')
                          OR PRM_TYPE LIKE 'DATETIME2([0-7])'
                          OR PRM_TYPE LIKE 'DECIMAL([1-5][0-9],[1-5][0-9])'
                          OR PRM_TYPE LIKE 'VACHAR([0-2][0-9],[0-5])'))

Un exemple de remplissage

Code:

1
2
3
4
 INSERT INTO T_PARAM_PRM VALUES 
('APPLICATION.NAME', 'Mon Appli à moi', 'VARCHAR(050)'),
('APPLICATION.INSTALL.DATE', '2010-01-01', 'DATE'),
('APPLICATION.INSTALL.VERSION', '123.45', 'FLOAT')

A +

16/02/2016, 15h56
NoPr0n

Merci, cela confirme ce que je pensais faire en ajoutant même quelques détails (comme le typage).
Je pense que je peux marquer le sujet en résolu.