Conseil pour la modélisation d'une base : Table "système", Enum .NET ou les 2 ?

Bonjour,

Je suis en train de réaliser un MCD et je souhaiterai avoir une base de données bien propre (comme tout le monde, quoi :D).
Je me posais une question toute bête par rapport aux données "système" (j'entends par-là les données liées à l'application et qui n'évolueront pas sans une intervention du développeur). Faut-il mettre ces valeurs dans une table, dans une énumération dans le code, ou bien dans les 2 ?

Par exemple, je souhaite mettre en place des alertes pour les utilisateurs (dépassement d'un certain seuil, détection de certaines erreurs dans le log...). L'utilisateur aura la main sur certains paramétrages tels que les seuils, qui alerter, comment alerter, fréquence de vérification... Donc là-dessus, pas de problème on stocke en base tout ce paramétrage.
Mais il ne pourra pas créer un nouveau type alerte (ce qui doit être surveillé) ni ajouter un nouveau moyen d'alerter (mail, message dans l'application...) car ça impliquerai de modifier du code.
Où stocker ce genre de listes ? Je me disais qu'il fallait peut-être créer des énumérations dans le code avec une fonction qui irait automatiquement remplir une table si les valeurs n'existent pas encore, ça permettrait par exemple d'associé un libellé détaillé (voire peut-être multilingue un jour) à une énumération. Et ainsi, le paramétrage lié à une alerte serait lié à l'identifiant de celle-ci plutôt qu'a son code d'énumération. Je ne sais pas trop si c'est une bonne idée ?

Tous vos conseils sont les bien venus.

Merci d'avance.

Salut,

La question est recurrente et malheuresement, il n'y a pas forcement de bonne reponse:

Tout d'abord est-ce que ton appli est la seule a taper sur la bdd, car si non, fais une table de parametrage avec fk la totale sinon tu va pleurer.

Cote enum only les plus:

• simple
• Directment switch case
• pas d'acces bdd inutile

les moins:

• pas de contrainte cote bdd
• localisation
• modifier un enum force a tout livrer
• en terme de dependances c'est pas forcement la panacee

La table de reference only, les plus:

• Les contraintes de bdd
• la possibilite de livrer a chaud
• pouvoir faire evoluer le modele facilement (imagine une colonne sort, une autre de droit etc)

Les moins:

• presque forcer de doublonner le code cote dotnet
• faire des script de bdd

Ensuite dans les deux cas, demain tu as de nombreuse tables de parametrages, as-tu un moyen facile de faire des requetes dessus?
=> pense a une interface et methode d'extention dessus.


La solutions vers laquelle je partirai (pas forcement la meilleure):

• Une table par type de reference
• Pas d'enum cote dotnet mais une classe couple avec factory et strategy en design patterns

Les plus: sans doute le plus souple
Les moins: sans doute le plus complique


Voila tiens-nous au courant de ton choix, bonne chance.

Merci pour la réponse, ça m'éclaircit un peu les idées même si c'est pas encore complétement clair dans ma tête.
La poursuite de l'analyse devrait m'aider à voir un peu mieux les choses mais je vais partir sur des tables dans la base pour avoir les contraintes pour lier le paramétrage. Après, côté code, je pense que je vais me faire une classe "Alerte" avec éventuellement une surcharge pour certaines alertes particulières. Et je pense que je vais prévoir une fonction pour initialiser en base les différentes alertes possibles.

Je ne sais pas trop si ça correspond à ce que tu disais, je n'ai pas suffisamment d'expérience pour comprendre ce genre de phrase :weird: :

Citation:

---

une classe couple avec factory et strategy en design patterns

---

Si j'y pense, j'essayerai de compléter ce post lorsque la solution définitive sera développée. En attendant, je marque résolu car comme tu dis, il n'y a pas vraiment de bonne réponse...