9
votes

Fichiers de configuration VS Tables de base de données VS

Le scénario que je suis particulièrement intéressé est de multiples serveurs ayant des démons qui fonctionnent sur certains paramètres de configuration. (Depuis, c'est un exercice d'apprentissage. Je me félicite de toute pensée au-delà de ce cas particulier) La question est de savoir où les paramètres de configuration doivent-ils s'asseoir.

a. une table de base de données centrale

b. Un fichier de configuration poussé à chacune des cases

Ce sont les plus courants que j'ai rencontrés. Les notables d'autres étant, dans les constantes de code (ont besoin de recompiler pour se déployer. Donc, une mauvaise option sauf si elles sont vraiment des constantes), configez le fichier monté sur un emplacement partagé.

Je voulais juste savoir de la communauté sur la façon dont vous allez faire le choix.


0 commentaires

3 Réponses :


6
votes

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

Si le nombre d'emplacements est important et / ou des modifications sont fréquents, utilisez une base de données.

Sinon, utilisez les fichiers de configuration.

Si l'accès à une base de données centralisée est trop lent ou inacceptablement un point d'échec, mais la balance est toujours grande, utilisez un système automatisé comme marionnette.


2 commentaires

Le dernier point peut être atténué par un cache esclave et requête.


Ma préférence serait pour la base de données lorsque cela est possible. Je suis disposé à payer les coûts de performance sur la mise en service des applications. Il existe plus d'options pour sécuriser la base de données qu'un fichier de configuration.



2
votes

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 stocker dans une base de données relationnelle à domicile. Je dirais que la balance n'a même pas d'importance. Devoir 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 à accéder. J'ai vu ce type de configuration utilisée sur 3 entreprises différentes et le seul endroit qu'il a été utilisé de manière vraiment réussie, était l'endroit où l'application a été exposée à une interface utilisateur simple permettant aux administrateurs système de modifier les paramètres. Si cela est uniquement accessible en utilisant un client SQL, vous constaterez que les configurations deviendront facilement «perdues» ou pire, dupliquées.

La marionnette mentionnée ci-dessus, que je n'ai jamais utilisée, mais cela a l'air très intéressant. Cependant, il ne semble pas que cela prend en charge Windows (1]: http: //www.puppetlabs. Com / Puppet / Exigences /


1 commentaires

Acceptez d'avoir une interface utilisateur / ou d'au moins une API pour accéder aux paramètres. Il limite la façon dont vous pouvez obtenir / définir des paramètres de configuration et bien sûr vous permet de passer en arrière N-à-d. Entrez entre les fichiers de configuration et les tables de DB :)



3
votes

Si les propriétés de configuration peuvent être mises à jour au moment de l'exécution, centraliser les propriétés de la DB faciliteront la vie.


0 commentaires