¿Debo usar un archivo de configuración o una base de datos para almacenar reglas comerciales?

Recientemente he estado leyendo El programador pragmático que dice que:

Los detalles estropean nuestro código original, especialmente si cambian con frecuencia. Cada vez que tenemos que entrar y cambiar el código para acomodar algún cambio en la lógica de negocios, en la ley o en los gustos personales de la administración del día, corremos el riesgo de romper el sistema, de introducir un nuevo error.

Caza, Andrew; Thomas, David (1999-10-20). El programador pragmático: de oficial a maestro (ubicaciones de Kindle 2651-2653). Pearson Education (Estados Unidos). Versión Kindle.

Actualmente estoy programando una aplicación web que tiene algunos modelos que tienen propiedades que solo pueden ser de un conjunto de valores, por ejemplo (no es un ejemplo real ya que los datos de la aplicación web son confidenciales):

luz-> tipo = esfera / cubo / cilindro

El tipo de luz solo puede ser los tres valores anteriores, pero de acuerdo con TPP, siempre debería codificar como si pudieran cambiar y colocar sus valores en un archivo de configuración. Como hay varios incidentes de esto en toda la aplicación, mi pregunta es:

¿Debo almacenar posibles valores como estos en:

• un archivo de configuración:
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• una sola tabla en una base de datos con una línea para cada elemento de configuración

• una base de datos con una mesa para cada elemento de configuración (por ejemplo, tabla: light_types; columnas: id, name)

• alguna otra forma?

Muchas gracias por cualquier ayuda / experiencia ofrecida.

La misma pregunta surge en la mayoría de los proyectos en los que trabajo. Por lo general, hago esto:

1. Si es improbable que el conjunto de valores posibles cambie pronto, utilizo constantes de clase / interfaz o enumeraciones en el código y campos enumerables en la base de datos. Ejemplo: estado de publicación de entradas de blog: 'no publicado', 'bajo moderación', 'publicado', etc.
2. Los valores probablemente cambiarán, pero los cambios no afectarán la lógica del programa: los archivos de configuración. Ejemplo: lista de "¿cómo encontró nuestro sitio web?" opciones para una lista desplegable en el formulario de compra en línea.
3. Es probable que los valores cambien con frecuencia y / o estén destinados a ser editados por no desarrolladores, pero estos cambios no afectarán la lógica: una base de datos o al menos un almacenamiento de valores clave con alguna interfaz fácil de usar para editar.
4. Cambiar los valores afectará la lógica: probablemente el sistema necesita un nuevo diseño (a menudo verdadero) o se necesita algún motor de reglas de negocio. El caso más difícil que he visto hasta ahora fue el constructor de pruebas psicológicas en el que trabajó mi colega. Cada tipo de prueba puede tener su propio sistema de puntuación, que puede variar desde la simple adición a múltiples escalas de características con valores positivos y negativos o incluso la evaluación humana de las respuestas. Después de una discusión sobre este proyecto, terminamos usando Lua como un motor de secuencias de comandos, lo que está totalmente en conflicto con la capacidad de los no desarrolladores para crear nuevas pruebas (a pesar de que Lua es un lenguaje relativamente simple, no debe esperar que un no programador lo aprenderé)

Sobre la cita de TPP. Creo que es cierto para prístina código, pero en la vida real, es mejor empezar sencilla ( principio KISS ) y añadir características más tarde si son realmente necesarios ( YAGNI ).

Si sus datos estarán en una base de datos, recomendaría tener una tabla de 'light_types' en el mismo DB. Esto le brinda la capacidad de usar claves externas para imponer una restricción de que light-> type solo puede ser uno de esos valores, por lo que incluso si el código se estropea, los datos en la base de datos siempre serán válidos.

Si los datos no se almacenarán en una base de datos, crear uno solo para un montón de enumeraciones no sirve de mucho. Podría recomendar un archivo de configuración, si realmente desea evitar codificar los valores.

(Sin embargo, advertiría contra ir demasiado lejos al evitar la codificación rígida. En cualquier sistema no trivial, habrá suposiciones sobre las reglas y requisitos comerciales, ya sea que los autores se den cuenta o no. Incluso si de alguna manera logras evitar todo supuestos y código suave absolutamente todo, básicamente terminas con un "motor de reglas", una especie de sistema dentro de un sistema y / o metalenguaje, y tienes un montón de cosas en el metalenguaje para implemente las reglas. No ha guardado ningún trabajo ni ha ganado flexibilidad, solo ha tenido que construir y / o aprender otro idioma.

Ahora, si desea encontrar y usar un motor de reglas existente, eso podría ahorrarle un poco de trabajo (junto con responder a la pregunta de dónde almacenar enumeraciones). Pero construir el suyo solo duplica la carga de trabajo e inevitablemente le da un sistema a medias hecho por personas que realmente no saben cómo hacer un motor de reglas decente).

En general, se debe usar una base de datos para los datos y un archivo de configuración para la configuración. (Como el nombre sugiere :) ). Mantener la configuración en la base de datos es una mala separación de las preocupaciones y solo debe hacerse si tiene un buen caso de uso para justificarlo.

Hay que lograr un equilibrio al decidir cuánta configuración usar. Debe tratar sus archivos de configuración tanto como una parte de una aplicación como el código. Mantenlo lo más conciso posible. Es muy fácil que las aplicaciones sufran una hinchazón de configuración donde terminas con un gran archivo xml lleno de cadenas mágicas.

En el caso que describa, sería razonable tener un elemento de configuración para definir qué archivo css usar. (podría cambiarlo si los requisitos cambian). Sería excesivo configurar el estilo de cada elemento en el archivo de configuración