Pregunta

¿Cuál es el método preferido de las personas para almacenar los datos de configuración de la aplicación en una base de datos? De haber hecho esto en el pasado, he utilizado dos formas de hacerlo.

  1. Puede crear una tabla donde almacene pares clave / valor, donde clave es el nombre de la opción de configuración y valor es su valor. Pro de esto es que agregar nuevos valores es fácil y puede usar las mismas rutinas para configurar / obtener datos. Las desventajas son que tienes datos sin tipo como valor.
  2. Alternativamente, puede codificar una tabla de configuración, siendo cada columna el nombre del valor y su tipo de datos. La desventaja de esto es que hay más mantenimiento al configurar nuevos valores, pero le permite tener datos escritos.

Habiendo usado ambos, mis preferencias se encuentran en la primera opción, ya que es más rápido de configurar, sin embargo, también es más riesgoso y puede reducir el rendimiento (ligeramente) al buscar datos. ¿Alguien tiene algún método alternativo?

Actualizar

Es necesario almacenar la información en una base de datos porque, como se indica a continuación, puede haber varias instancias del programa que requieran la configuración de la misma forma, así como procedimientos almacenados que potencialmente utilizan los mismos valores.

¿Fue útil?

Solución

Puede expandir la opción 1 para tener una tercera columna, dando un tipo de datos. Su aplicación puede usar esta columna de tipo de datos para emitir el valor.

Pero sí, me gustaría ir con la opción 1, si los archivos de configuración no son una opción. Otra ventaja de la opción 1 es que puedes leerlo en un objeto de Diccionario (o equivalente) para usar en tu aplicación de manera muy fácil.

Otros consejos

Como la configuración normalmente se puede almacenar en un archivo de texto, el tipo de datos de cadena debe ser más que suficiente para almacenar los valores de configuración. Si está utilizando un idioma administrado, es el código el que sabe cuál debe ser el tipo de datos, no la base de datos.

Más importante, considera estas cosas con la configuración:

  • Jerarquía : Obviamente, la configuración se beneficiará de una jerarquía
  • Versiones : considere la ventaja de poder revertir a la configuración que estaba vigente en una fecha determinada.
  • Distribución : en algún momento, puede ser bueno poder agrupar una aplicación. Algunas propiedades probablemente deberían ser locales para cada nodo en un clúster.
  • Documentación : dependiendo de si tiene una herramienta web o algo así, es probable que sea bueno almacenar la documentación sobre una propiedad cerca del código que la usa. (Las anotaciones de código son muy buenas para esto).
  • Notificación : ¿Cómo sabrá el código que se ha realizado un cambio en algún lugar del repositorio de configuración?

Personalmente, me gusta una forma invertida de manejar la configuración, donde las propiedades de configuración se inyectan en los módulos que no saben de dónde provienen los valores. De esta manera, el sistema de administración de la configuración puede ser muy complejo o muy simple dependiendo de sus necesidades (actuales).

Yo uso la opción 1.

Parece excesivo utilizar la base de datos para los datos de configuración.

EDITAR (lo siento demasiado tiempo para el cuadro de comentarios): Por supuesto, no hay reglas estrictas sobre cómo implementar cualquier parte de su programa. Por el bien de la discusión, ¡los destornilladores ranurados funcionan en algunos tornillos philips! Supongo que lo juzgué demasiado pronto antes de saber cuál es tu situación.

La base de datos relacional se destaca en el almacén de datos masivos que le brinda almacenamiento, actualización y recuperación rápidos, por lo que si sus datos de configuración se actualizan y leen constantemente, entonces, por supuesto, use db.

Otro escenario en el que db puede tener sentido es cuando tiene una granja de servidores donde desea que su base de datos almacene su configuración central, pero luego puede hacer lo mismo con una unidad de red compartida que apunte al archivo de configuración XML.

El archivo XML es mejor cuando su configuración está estructurada jerárquicamente. ¡Puede organizar, localizar y actualizar fácilmente lo que necesita, y para obtener un beneficio adicional, puede controlar el archivo de configuración junto con su código fuente!

En general, todo depende de cómo se utilicen los datos de configuración.

Eso concluye mi opinión con un conocimiento limitado de su aplicación. Estoy seguro de que puedes tomar la decisión correcta.

Supongo que esto es más una encuesta, así que diré el enfoque de la columna (opción 2). Sin embargo, dependerá de la frecuencia con la que cambie la configuración, la dinámica de la misma y la cantidad de datos que haya, etc.

Ciertamente, usaría este enfoque para las configuraciones / preferencias de los usuarios, etc.

Mi proyecto utiliza una tabla de base de datos con cuatro columnas:

  1. ID [pk]
  2. Ámbito (predeterminado 'Aplicación')
  3. configuración
  4. valor

Las configuraciones con un alcance de 'Aplicación' son configuraciones globales, como Número máximo de usuarios simultáneos.

Cada módulo tiene su propio alcance basado; por lo tanto, nuestro ResultsLoader y UserLoader tienen diferentes ámbitos, pero ambos tienen una configuración llamada 'inputPath'.

Los valores predeterminados se proporcionan en el código fuente o se inyectan a través de nuestro contenedor IoC. Si no se inyecta ningún valor o no se proporciona en la base de datos, se utiliza el valor predeterminado del código (si existe). Por lo tanto, los valores predeterminados nunca se almacenan en la base de datos.

Esto funciona bastante bien para nosotros. Cada vez que hacemos una copia de seguridad de la base de datos obtenemos una copia de la Configuración que es bastante útil. Los dos siempre están sincronizados.

Ir con la opción 2. La opción 1 es realmente una forma de implementar una base de datos en la parte superior de una base de datos, y esa es una antipattern bien conocida, que a la larga le dará problemas.

Puedo pensar en al menos dos formas más:

(a) Cree una tabla con columnas de clave, valor de cadena, valor de fecha, valor int, valor real. Deje los tipos no utilizados en NULL.

(b) Use un formato de serialización como XML, YAML o JSON y guárdelo todo en un blob.

¿Dónde almacena los ajustes de configuración que necesita su aplicación para conectarse a la base de datos?

¿Por qué no almacenar la otra información de configuración allí también?

Iría con la opción 1, a menos que el número de opciones de configuración fuera MUY pequeño (siete o menos)

En mi empresa, estamos trabajando en el uso de la opción uno (una simple tabla similar a un diccionario) con un toque. Estamos permitiendo la sustitución de cadenas utilizando tokens que contienen el nombre de la variable de configuración que se va a sustituir.

Por ejemplo, la tabla puede contener filas ('cadena de conexión de base de datos', 'jdbc: //% host% ...') y ('host', 'foobar'). El hecho de encapsular eso con un servicio simple o una capa de procedimiento almacenado permite una configuración recursiva extremadamente simple, pero flexible. Es compatible con nuestra necesidad de tener múltiples entornos aislados (dev, test, prod, etc).

He usado tanto el 1 como el 2 en el pasado, y creo que ambos son soluciones terribles. Creo que la Opción 2 es mejor porque permite escribir, pero es mucho más desagradable que la opción 1. El mayor problema que tengo con cualquiera de ellos es la versión del archivo de configuración. Puede la versión de SQL razonablemente bien usando sistemas de control de versión estándar, pero la combinación de cambios suele ser problemática. Si tuviera la oportunidad de hacer esto "a la derecha", probablemente crearía un montón de tablas, una para cada tipo de parámetro de configuración (no necesariamente para cada parámetro en sí), obteniendo así el beneficio de escribir y el beneficio de la tecla / paradigma de valor cuando sea apropiado. También puede implementar estructuras más avanzadas de esta manera, como listas y jerarquías, que luego la aplicación podrá consultar directamente en lugar de tener que cargar la configuración y luego transformarla de alguna manera en la memoria.

Voto por la opción 2. Fácil de entender y mantener.

La opción 1 es buena para una ubicación de almacenamiento central fácilmente expandible. Además de algunas de las sugerencias de grandes columnas de personas como RB, Hugo y elliott, también podría considerar:

Incluya un indicador de configuración global / usuario con un campo de usuario o incluso un campo de usuario / máquina (para la configuración de tipo de interfaz de usuario específica de la máquina).

Por supuesto, estos pueden almacenarse en un archivo local, pero como de todos modos está utilizando la base de datos, esto hace que estén disponibles para el aliasing de un usuario al depurar, lo que puede ser importante si el error está relacionado con la configuración. También permite que un administrador administre las configuraciones cuando sea necesario.

Utilizo una combinación de columnas de opción 2 y XML en el servidor SQL. También es posible que no desee agregar una restricción de verificación para mantener la tabla en una fila.

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')
)

para configuraciones que no tienen relación con ninguna tabla de db, probablemente optaría por el enfoque de EAV si necesita el db para trabajar con los valores. de lo contrario, un valor de campo serializado es bueno si realmente es solo una tienda de código de aplicación.

pero ¿qué pasa con un formato para un solo campo para almacenar múltiples configuraciones de configuración para ser utilizadas por la db?

como un campo por usuario que contiene todas sus configuraciones relacionadas con la vista de su tablero de mensajes (como el orden predeterminado, temas bloqueados, etc.) y tal vez otra con todas sus configuraciones para su tema (como el color del texto, el color BG, etc. .)

El almacenamiento de la jerarquía y los documentos en un DB relacional es una locura. En primer lugar, o bien tienes que destruirlos, solo para volver a combinarlos en una etapa posterior. O que está dentro de un BLOB, aún más estúpido.

No utilice una base de datos relacional para datos no relacionales, la herramienta no se ajusta. Considere algo como MongoDB o CouchDB para esto. Almacenes de datos no relacionales sin esquema. Guárdelo como JSON si se está conectando de alguna manera a un cliente, use XML para servidores.

CouchDB te da el control de versiones fuera de la caja.

No almacene datos de configuración en una base de datos a menos que tenga una buena razón para hacerlo. Si tiene una buena razón y está absolutamente seguro de que lo va a hacer, probablemente debería almacenarlo en un formato de serialización de datos como JSON o YAML (no XML, a menos que realmente necesite un lenguaje de marcado para configurar su aplicación - - confía en mí, no lo haces) como una cadena. Luego, simplemente puede leer la cadena y usar las herramientas en el idioma en el que trabaje para leerla y modificarla. Almacene las cadenas con marcas de tiempo y tendrá un esquema de control de versiones simple con la capacidad de almacenar datos jerárquicos en un sistema muy simple. Incluso si no necesita datos de configuración jerárquicos, al menos ahora, si los necesita en el futuro, no tendrá que cambiar la interfaz de configuración para obtenerlos. Por supuesto, pierde la capacidad de hacer consultas relacionales en sus datos de configuración, pero si está almacenando esa gran cantidad de datos de configuración, probablemente esté haciendo algo muy mal de todos modos.

Las empresas tienden a almacenar lotes de datos de configuración para sus sistemas en una base de datos, no estoy seguro de por qué, no creo que se piense mucho en estas decisiones. No veo que se haga este tipo de cosas con demasiada frecuencia en el mundo OSS. Incluso los programas OSS grandes que necesitan mucha configuración como Apache no necesitan una conexión a una base de datos que contenga una tabla apache_config para funcionar. Tener una gran cantidad de configuraciones con las que lidiar en tus aplicaciones es un mal olor de código, almacenar esos datos en una base de datos solo causa más problemas (como lo ilustra este hilo).

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top