Fichiers de configuration vs tables de base de données

Question

Le scénario qui m'intéresse particulièrement est celui des serveurs multiples ayant des démons qui s'exécutent sur certains paramètres de configuration. (depuis, c'est un exercice d'apprentissage, je me réjouis de toute pensée au-delà de ce cas particulier) La question est, où devraient se situer les paramètres de configuration.

A. une table de base de données centrale

B. un fichier de configuration poussé à chacune des boîtes

Ce sont je suis venu à travers le plus commun. Les autres notables étant, dans les constantes de code (besoin de recompiler pour déployer, si mauvaise option à moins qu'ils ne soient vraiment des constantes), le fichier de configuration est monté sur un emplacement partagé.

Je voulais juste savoir de la communauté sur comment vous allez faire le bon choix.

Answer 1

Tout dépend de l'ampleur de l'opération que vous gérez.

Si le nombre d'emplacements est grand et/ou les changements sont fréquents, utilisez une base de données.

Sinon, utilisez des fichiers de configuration.

Si l'accès à une base de données centralisée est un point de défaillance trop lent ou inacceptable, mais que l'échelle est toujours importante, utilisez un système automatisé tel que Puppet.

Answer 2

La plupart des entreprises ayant besoin de partager des paramètres de configuration entre serveurs/applications finissent par créer leurs propres mécanismes de configuration et les stockent dans une base de données relationnelle interne. Je dirais que l'échelle n'a même pas d'importance. Avoir à se connecter à plusieurs serveurs afin de vérifier une configuration sur le système de fichiers est un cauchemar. Cependant, même lors de la gestion de la configuration dans une base de données centrale, vous devez toujours vous assurer que la configuration est facile d'accès. J'ai vu ce type de configuration utilisé dans trois entreprises différentes, et le seul endroit où il a été utilisé avec succès était l'endroit où l'application exposait une interface utilisateur simple permettant aux administrateurs système de modifier les paramètres. Si elle est uniquement accessible en utilisant un client SQL, vous trouverez que les configurations seront facilement "perdues" ou pire, dupliquées.

L'affiche ci-dessus Marionnettes, que je ne l'ai jamais utilisé, mais il semble très intéressant. Cependant, il ne semble pas encore prendre en charge Windows [1]:

Answer 3

Si les propriétés de configuration peuvent être mises à jour lors de l'exécution, la centralisation des propriétés dans le DB simplifiera la vie.