Archivos de configuración frente a tablas de base de datos

Question

El escenario en el que estoy particularmente interesado es en servidores múltiples que tienen daemons que se ejecutan en ciertos parámetros de configuración. (dado que este es un ejercicio de aprendizaje. Acepto cualquier pensamiento más allá de este caso particular) La pregunta es, ¿dónde deberían estar los parámetros de configuración?

A. una tabla de base de datos central

B. un archivo de configuración empujó a cada una de las cajas

Estos son los más comunes que he encontrado. Los otros notables son, en las constantes de código (necesita recompilar para implementar. Mala opción a menos que realmente sean constantes), archivo de configuración montado en una ubicación compartida.

Solo quería saber de la comunidad cómo va a hacer la elección.

Answer 1

Todo depende de la escala de la operación que está administrando.

Si el número de ubicaciones es grande y/o los cambios son frecuentes, utilice una base de datos.

De lo contrario, utilice los archivos de configuración.

Si el acceso a una base de datos centralizada es demasiado lento o inaceptablemente un punto de falla, pero la escala sigue siendo grande, use un sistema automatizado como Puppet.

Answer 2

La mayoría de las empresas que necesitan compartir parámetros de configuración entre servidores/aplicaciones terminan creando sus propios mecanismos de configuración y almacenándolos en una base de datos relacional hogareña. Yo diría que la báscula ni siquiera importa. Tener que iniciar sesión en varios servidores para verificar una configuración en el sistema de archivos es una pesadilla. Sin embargo, incluso al administrar la configuración en una base de datos central, aún debe asegurarse de que la configuración sea de fácil acceso. He visto este tipo de configuración utilizada en 3 compañías diferentes, y el único lugar donde se utilizó de manera verdaderamente exitosa fue donde la aplicación expuso una interfaz de usuario simple que permite a los administradores del sistema modificar la configuración. Si solo se puede acceder utilizando un cliente SQL, encontrará que las configuraciones se "perderán" fácilmente o, lo que es peor, se duplicarán.

El cartel mencionado anteriormente Marioneta, que nunca he usado, pero se ve MUY interesante. Sin embargo, parece que aún no es compatible con Windows [1]: http://www.puppetlabs.com/puppet/requirements/

Answer 3

Si las propiedades de configuración se pueden actualizar en tiempo de ejecución, la centralización de las propiedades en el DB facilitará la vida.