Para mí, si vas en una fila o en EAV, depende de cómo quieras consumirlos.
El poder de EAV es que se pueden agregar nuevos datos sin cambiar la estructura. Esto significa que si desea un nuevo valor de configuración, simplemente lo agrega a la tabla y lo saca en el código que desea, y no necesita agregar un nuevo campo al dominio, esquema, asignación, consultas DAL , etc.
Su defecto es que solo tiene la estructura más simple, lo que requiere que usted maneje los datos de manera pesimista. Cada uso de cualquier valor de configuración debe esperar que el valor no esté presente, o no en el formato adecuado, y comportarse en consecuencia cuando no lo esté. Un valor de configuración no se puede analizar en un doble, un int o un char. Puede ser nulo. Puede que no haya ninguna fila para el valor en absoluto. Las formas de evitar esto generalmente requieren que exista un único valor "predeterminado" válido para todos los valores de configuración de un tipo de código en particular ( extremadamente raro; más a menudo el valor predeterminado es tan problemático para consumir código como ninguno en absoluto), o mantener un diccionario codificado de valores predeterminados (que debe cambiar cada vez que se agregue una nueva columna, lo que hace que la ventaja principal del almacenamiento de EAV sea bastante discutible).
Una sola fila ancha es más o menos lo contrario. Usted lo asigna a una sola instancia de un objeto de configuración con un campo / propiedad para cada valor de configuración existente. Sabe exactamente qué tipo de valores deberían tener esos valores en el momento de la compilación, y "falla rápidamente" en el DAL si no existe una columna de configuración o no tiene un valor del tipo adecuado, lo que le brinda un lugar para detectar excepciones en función en la recuperación de la configuración / problemas de hidratación.
La principal desventaja es que se requiere un cambio estructural para cada nuevo valor; Nueva columna de base de datos, nueva columna en el DAL (ya sea la asignación o las consultas SQL / SP), nueva columna de dominio, todo lo necesario para probar el uso correctamente.
La situación adecuada para utilizar cualquiera de estos es la situación en la que se mitigan las desventajas. Para mí, la mayoría de las situaciones de codificación de configuración han requerido una implementación de una sola fila. Esto se debe principalmente a que si está introduciendo un valor de configuración completamente nuevo que rige el comportamiento de alguna parte de su programa, ya tiene que cambiar el código para utilizar el nuevo valor de configuración; ¿por qué no saltar al objeto de configuración y agregar el valor que se usará?
En resumen, un esquema de EAV para almacenar la configuración realmente no resuelve el problema que pretende resolver, y la mayoría de las soluciones a los problemas que presenta violan DRY.