Question

Quelle est la méthode préférée des personnes pour stocker les données de configuration de l'application dans une base de données. Ayant moi-même déjà fait cela par le passé, j'ai utilisé deux méthodes.

  1. Vous pouvez créer une table dans laquelle vous stockez des paires clé / valeur, où clé est le nom de l'option de configuration et la valeur, sa valeur. Il est facile d'ajouter de nouvelles valeurs et vous pouvez utiliser les mêmes routines pour définir / obtenir des données. Inconvénients, vous avez des données non typées comme valeur.
  2. Vous pouvez également coder en dur une table de configuration, chaque colonne étant le nom de la valeur et son type de données. L’inconvénient, c’est plus de maintenance qui configure de nouvelles valeurs, mais cela vous permet d’avoir des données saisies.

Ayant utilisé les deux, mes préférences concernent la première option, car elle est plus rapide à configurer, mais elle est également plus risquée et peut réduire les performances (légèrement) lors de la recherche de données. Quelqu'un a-t-il une autre méthode?

Mettre à jour

Il est nécessaire de stocker les informations dans une base de données car, comme indiqué ci-dessous, plusieurs instances du programme peuvent nécessiter une configuration identique, ainsi que des procédures stockées utilisant potentiellement les mêmes valeurs.

Était-ce utile?

La solution

Vous pouvez développer l'option 1 pour avoir une 3ème colonne, donnant un type de données. Votre application peut ensuite utiliser cette colonne de type de données pour transtyper la valeur.

Mais oui, je choisirais l'option 1 si les fichiers de configuration ne sont pas une option. Un autre avantage de l'option 1 est que vous pouvez le lire facilement dans un objet Dictionnaire (ou son équivalent) pour l'utiliser dans votre application.

Autres conseils

Étant donné que la configuration peut généralement être stockée dans un fichier texte, le type de données chaîne devrait être plus que suffisant pour stocker les valeurs de configuration. Si vous utilisez une langue gérée, c'est le code qui définit le type de données, pas la base de données.

Plus important encore, tenez compte de ces éléments lors de la configuration:

  • Hiérarchie : il est évident que la configuration bénéficiera d'un hiérarchie
  • Gestion des versions : réfléchissez à l'avantage de pouvoir revenir à la configuration en vigueur à une certaine date.
  • Distribution : à un moment ou à un autre, il peut être intéressant de pouvoir mettre en cluster une application. Certaines propriétés devraient probablement être locales pour chaque nœud d'un cluster.
  • Documentation : selon que vous possédez un outil Web ou autre, il est probablement agréable de stocker la documentation relative à une propriété proche du code qui l'utilise. (Les annotations de code sont très utiles pour cela.)
  • Notification : comment le code saura-t-il qu'une modification a été apportée quelque part dans le référentiel de configuration?

Personnellement, j’aime une méthode de gestion de la configuration inversée, dans laquelle les propriétés de configuration sont injectées dans les modules qui ne savent pas d’où viennent les valeurs. Ainsi, le système de gestion de la configuration peut être très complexe ou très simple en fonction de vos besoins (actuels).

J'utilise l'option 1.

Il semble excessif d’utiliser la base de données pour les données de configuration.

EDIT (désolé trop long pour la boîte de commentaire): Bien sûr, il n’ya pas de règles strictes sur la manière de mettre en œuvre une partie de votre programme. Par souci d'argumentation, les tournevis à fente fonctionnent sur des vis Philips! Je suppose que j'ai jugé trop tôt avant de savoir quel est votre scénario.

La base de données relationnelle excelle dans le stockage massif de données qui vous permet de stocker, de mettre à jour et de récupérer rapidement. Ainsi, si vos données de configuration sont mises à jour et lues en permanence, utilisez bien db.

Un autre scénario où la base de données peut sembler logique est le cas où vous avez une batterie de serveurs sur laquelle votre base de données doit stocker votre configuration centrale, mais vous pouvez ensuite faire de même avec un lecteur réseau partagé pointant vers le fichier de configuration xml.

Le fichier XML est préférable lorsque votre configuration est structurée de manière hiérarchique. Vous pouvez facilement organiser, localiser et mettre à jour ce dont vous avez besoin, et pour bénéficier de bonus, vous pouvez contrôler le version du fichier de configuration avec votre code source!

Dans l’ensemble, tout dépend de la manière dont les données de configuration sont utilisées.

Ceci conclut mon opinion avec une connaissance limitée de votre application. Je suis sûr que vous pouvez prendre la bonne décision.

Je suppose qu’il s’agit plus d’un sondage, je dirai donc l’approche par colonnes (option 2). Cependant, cela dépendra de la fréquence à laquelle votre configuration change, de sa dynamique, de la quantité de données, etc.

J'utiliserais certainement cette approche pour les configurations / préférences utilisateur, etc.

Mon projet utilise une table de base de données à quatre colonnes:

  1. ID [pk]
  2. Portée ("Application" par défaut)
  3. Paramétrage
  4. valeur

Les paramètres avec une étendue de 'Application' sont des paramètres globaux, tels que Nombre maximal d'utilisateurs simultanés.

Chaque module a sa propre portée. Ainsi, ResultsLoader et UserLoader ont des portées différentes, mais les deux ont un paramètre nommé 'inputPath'.

Les valeurs par défaut sont soit fournies dans le code source, soit injectées via notre conteneur IoC. Si aucune valeur n'est injectée ou fournie dans la base de données, le code par défaut du code est utilisé (le cas échéant). Par conséquent, les valeurs par défaut ne sont jamais stockées dans la base de données.

Cela fonctionne assez bien pour nous. Chaque fois que nous sauvegardons la base de données, nous obtenons une copie de la configuration, ce qui est très pratique. Les deux sont toujours synchronisés.

Choisissez l’option 2. L'option 1 est vraiment un moyen d'implémenter une base de données sur une base de données, et c'est un anti-modèle bien connu, qui ne va que vous poser problème à long terme.

Je peux penser à au moins deux autres moyens:

(a) Créez une table avec des colonnes clé, valeur chaîne, valeur date, valeur int, valeur réelle. Laissez les types non utilisés NULL.

(b) Utilisez un format de sérialisation tel que XML, YAML ou JSON et stockez le tout dans un blob.

Où stockez-vous les paramètres de configuration dont votre application a besoin pour se connecter à la base de données?

Pourquoi ne pas stocker les autres informations de configuration là aussi?

Je choisirais l'option 1, à moins que le nombre d'options de configuration ne soit TRÈS petit (sept ou moins)

Dans mon entreprise, nous travaillons sur l’option 1 (un simple tableau ressemblant à un dictionnaire) avec une torsion. Nous autorisons la substitution de chaînes à l'aide de jetons contenant le nom de la variable de configuration à substituer.

Par exemple, la table peut contenir des lignes ("chaîne de connexion à la base de données", "jdbc: //% host% ...") et ("host", "foobar"). En encapsulant cela avec un simple service ou une couche de procédure stockée, on obtient une configuration récursive extrêmement simple, mais flexible. Cela répond à notre besoin d'avoir plusieurs environnements isolés (dev, test, prod, etc.).

J'ai utilisé à la fois 1 et 2 dans le passé et je pense que ce sont deux solutions terribles. Je pense que l’option 2 est meilleure car elle permet de taper, mais c’est beaucoup plus moche que l’option 1. Le plus gros problème que j’ai avec l’une ou l’autre est la gestion des versions du fichier de configuration. Vous pouvez raisonnablement utiliser la version SQL avec des systèmes de contrôle de version standard, mais la fusion des modifications est généralement problématique. Si je pouvais le faire "correctement", je créerais probablement plusieurs tables, une pour chaque type de paramètre de configuration (pas nécessairement pour chaque paramètre lui-même), ce qui permettrait de tirer parti des avantages de la frappe et de la clé / paradigme de la valeur, le cas échéant. Vous pouvez également implémenter des structures plus avancées, telles que des listes et des hiérarchies, qui seront alors directement interrogeables par l'application au lieu de devoir charger la configuration puis de la transformer en quelque sorte en mémoire.

Je vote pour l'option 2. Facile à comprendre et à gérer.

L'option 1 convient à un emplacement de stockage central facilement extensible. Outre certaines des excellentes suggestions de chroniques proposées par des personnalités telles que RB, Hugo et elliott, vous pouvez également envisager:

Incluez un indicateur de paramètre global / utilisateur dans un champ utilisateur ou même un champ utilisateur / machine (pour les paramètres de type d'interface utilisateur spécifiques à la machine).

Ceux-ci peuvent, bien sûr, être stockés dans un fichier local, mais puisque vous utilisez quand même la base de données, cela les rend disponibles pour créer un alias pour un utilisateur lors du débogage - ce qui peut être important si le bogue est lié à la définition. Il permet également à un administrateur de gérer les réglages si nécessaire.

J'utilise un mélange de colonnes option 2 et XML dans SQL Server. Vous pouvez également ajouter une contrainte de vérification pour conserver le tableau sur une ligne.

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

pour les paramètres qui n’ont aucune relation avec les tables de base de données, j’irais probablement pour l’approche EAV si vous avez besoin que la base de données fonctionne avec les valeurs. sinon, une valeur de champ sérialisée est bonne s'il ne s'agit que d'un magasin de code d'application.

mais qu'en est-il d'un format pour un champ unique permettant de stocker plusieurs paramètres de configuration à utiliser par la base de données?

comme un champ par utilisateur contenant tous les paramètres associés à la vue du panneau de message (ordre de tri par défaut, sujets bloqués, etc.), et éventuellement un autre avec tous les paramètres du thème (couleur du texte, couleur de fond, etc.) .)

Le stockage de la hiérarchie et des documents dans une base de données relationnelle est une folie. Premièrement, vous devez soit les déchiqueter, mais seulement pour les recombiner à un stade ultérieur. Ou là, coincé dans un BLOB, encore plus stupide.

N'utilisez pas une base de données relationnelle pour des données non relationnelles, l'outil ne tient pas. Envisagez quelque chose comme MongoDB ou CouchDB pour cela. Magasins de données sans relation sans schéma. Stockez-le en tant que JSON s'il parvient de quelque manière que ce soit à un client, utilisez XML pour serveride.

CouchDB vous offre une gestion des versions immédiate.

Ne stockez pas les données de configuration dans une base de données sauf si vous avez une très bonne raison de le faire. Si vous avez une très bonne raison et êtes absolument certain de le faire, vous devriez probablement le stocker dans un format de sérialisation des données tel que JSON ou YAML (pas XML, sauf si vous avez réellement besoin d'un langage de balisage pour configurer votre application). - croyez-moi, vous ne le faites pas) en chaîne. Ensuite, vous pouvez simplement lire la chaîne et utiliser des outils dans la langue dans laquelle vous travaillez pour la lire et la modifier. Stockez les chaînes avec des horodatages et vous disposez d'un schéma de gestion de version simple permettant de stocker des données hiérarchiques dans un système très simple. Même si vous n'avez pas besoin de données de configuration hiérarchiques, au moins maintenant, si vous en avez besoin à l'avenir, vous n'aurez pas à changer votre interface de configuration pour l'obtenir. Bien sûr, vous perdez la possibilité d'effectuer des requêtes relationnelles sur vos données de configuration, mais si vous stockez cette quantité de données de configuration, vous faites probablement quelque chose de très mal de toute façon.

Les entreprises ont tendance à stocker beaucoup de données de configuration de leurs systèmes dans une base de données. Je ne sais pas pourquoi, je ne pense pas que ces décisions soient prises en compte. Je ne vois pas ce genre de chose se faire trop souvent dans le monde des logiciels libres. Même les grands programmes OSS nécessitant beaucoup de configuration, comme Apache, n'ont pas besoin de connexion à une base de données contenant une table apache_config pour fonctionner. Avoir une énorme quantité de configuration à gérer dans vos applications est une mauvaise odeur de code, le stockage de ces données dans une base de données ne fait que causer davantage de problèmes (comme l'illustre ce fil de discussion).

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top