¿Es una mala idea tener una tabla de propiedades en una base de datos?

A menudo, cuando necesito almacenar propiedades del sistema como información de administrador, versiones, etc., utilizo un archivo plano (database.properties, init.properties, etc.). Esto parece común en otros programas que veo y uso a diario.¿Es una mala idea tener una tabla de propiedades en una base de datos?

A veces, un archivo plano no es ideal por una serie de razones. La implementación de una aplicación web para numerosos clientes a menudo tiene limitaciones. En estos casos, utilizo una tabla de base de datos para contener la información. Por ejemplo, digamos que tengo algunos datos de administrador que deseo guardar, y tal vez algunos detalles sobre mi entorno. Yo podría hacer algo como esto:

property_entry_table

[id, scope, refId, propertyName, propertyValue, propertyType] 
1, 0, 1, "DB_VER", "2.3.0", "FLOAT" 
2, 0, 1, "LICENCE", "88475", "INT" 
3, 0, 1, "TOP_PROJECT", "1", "INT" 
4, 0, 1, "SHOW_WELCOME", "F", "BOOL" 
5, 0, 1, "SMTP_AUTH", "SSH", "STRING" 
6, 1, 1, "ADMIN_ALERTS", "T", "BOOL"

Comprendo que esto rompe la tipificación de SQL y me permite almacenar todo tipo de tipos como cadenas. ¿Es esta una buena práctica o he estado haciendo esto de la manera incorrecta?

Si no, ¿de qué forma debo almacenar este tipo de información?

Fuente

2010-02-23 Stephano

siempre que sea almacenamiento para algunas propiedades del sistema, etc., está bien. ¡No entiendo la idea de almacenar ** todos ** sus datos de esta manera! Vea aquí para una discusión, por qué: http://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/ –

también, quizás el impulso para esta pregunta, ¿por qué me rechazaron aquí ?: http://stackoverflow.com/questions/2300356/using-a-single-row-configuration-table-in-sql-server-database-bad-idea/2300450#2300450 – Stephano

He utilizado una estructura similar para almacenar datos de propiedad, y creo que está bien, siempre y cuando la tabla se mantenga relativamente pequeña. Una tabla de valor de atributo de entidad (EAV) puede consumir más espacio y mostrar un rendimiento de consulta más lento que una tabla estructurada en columnas tradicional, pero eso no debería ser un problema para un conjunto de propiedades de aplicación de tamaño razonable.

Fuente

2010-02-23 19:22:03 newdayrising

buen enlace. parece que tengo algo de lectura tarde para hacer. – Stephano

Esto está bien para pequeñas cantidades de datos a los que se accede con poca frecuencia.

En realidad, puede ser mejor para un usuario que mira el esquema no ver las propiedades de la aplicación individual.

Esto reduce los problemas con las actualizaciones de esquema. (Las propiedades de la aplicación se agregan/eliminan con frecuencia)

Lo que no es adecuado para grandes cantidades de datos o datos de acceso frecuente, ya que hay mucho más trabajo para la base de datos por recuperación y más espacio ocupado , que para un esquema convencional.

Fuente

2010-02-23 19:27:31 martinr

Creo que esto está bien, pero es posible que desee considerar el almacenamiento en caché de sus datos en la memoria cuando lo lea para que no tenga que seguir volviendo a la base de datos. Si almacena en caché sus datos, guárdelos donde sea que sus actualizaciones sean más fáciles. La ventaja de alojar los datos en su base de datos es que puede ser más fácil mantener o crear interfaces para administrar esas propiedades, especialmente una vez que comience a usar un entorno distribuido para su aplicación.

Fuente

2010-02-23 19:35:48 Middletone

idea interesante para almacenar en caché la información. Había hecho esto en el pasado guardando en caché algunos datos en la interfaz que necesitaba disponible. – Stephano

¿Es una mala idea tener una tabla de propiedades en una base de datos?

Respuesta

Cuestiones relacionadas