2010-03-08 7 views
5

Alguien sugirió mover una mesa llena de configuración, donde cada columna es un nombre de configuración (o tipo) y las filas son los clientes & sus respectivos ajustes para cada configuración.Diseño Tabla Para systemsettings, Mejor Modelo

ID | IsAdmin | ImagePath
------------------------------
12 | 1                     | \ camino \ a \ imágenes
34 | 0                     | \ path \ to \ images

La desventaja de esto es que cada vez que queremos un nuevo nombre de configuración (o tipo) alteramos la tabla (a través de sql) y agregamos el nuevo nombre/tipo de configuración (columna). Luego actualice las filas (para que cada cliente tenga ahora un valor para esa configuración).

La nueva propuesta de diseño de mesa. La propuesta es tener una columna para establecer el nombre y otra columna para establecer.
ID | SettingName | SettingValue
----------------------------
12 | IsAdmin               | 1
12 | ImagePath       | \ camino \ a \ imágenes
34 | IsAdmin               | 0
34 | ImagePath       | \ camino \ a \ imágenes

El punto que hicieron fue que agregar una nueva configuración era tan fácil como una simple instrucción de inserción en la fila, sin columna agregada.

Pero algo no se siente bien sobre el segundo diseño, se ve mal, pero no puedo llegar a ningún argumento en contra de ella. ¿Me equivoco?

Respuesta

2

Esta es una variación de un esquema "Entity Attribute Value" (Joel y random SO question)

Tiene algunos pros y contras más, y es casi seguro que terminará en lágrimas.

+0

Creo que usar EAV en la configuración está bien. Diseñar su base de datos completa en torno a EAV es una historia completamente diferente y no de lo que OP preguntó. Pero no veo la base de datos de documentos fundamentalmente diferentes desde su punto de vista, y no veo por qué el uso de ellos también podría terminar en lágrimas. –

+0

@Johannes Rudolph: para una tabla de configuración del sistema simple, entonces sí. Al igual que los juegos de aplicaciones en web.config, por ejemplo. Sin embargo, al igual que web.config, utiliza secciones dedicadas para configuraciones más complejas: no expande las aplicaciones. Y, finalmente, empeorará porque alguien pensará "qué gran idea". Diciendo eso, los he usado, pero debes tener cuidado ... – gbn

+0

Gracias por el aviso, esta era una versión (aproximada) de EAV, entre los enlaces y google, debería obtener algo. Parece que hay algunos problemas con la integridad referencial. Como crear una configuración DefaultReportID, 10 cuando exista en la tabla de informes del 1 al 9. –

1

El segundo enfoque realmente se asemeja a un diccionario. Considero que esta es una opción más conveniente para una aplicación en la que estoy trabajando por las razones que mencionaste. Hay algunas advertencias sobre este enfoque, por lo que debe tener cuidado con ellas:

  • Mantenga sus cadenas clave estáticas, nunca cambie el nombre.
  • Asegúrese de que cada vez que se recupera el diccionario de configuración, lo actualice a la versión más nueva (generalmente añadiendo claves y estableciendo valores predeterminados/solicitando al usuario).
  • Es complicado mezclar cadena y p. Ej. datos decimales, tendrá que elegir uno o proporcionar varias columnas con nulos para que pueda almacenar los datos en el formato apropiado. Mantenga esos metadatos en algún lado.
  • El código que se encarga del diccionario debe envolver de manera inflexible, no debe ser expuesto como un diccionario real (en el sentido de una estructura de datos), proporcionar una clase en su lugar.
+0

Me di cuenta de que también era un diccionario, puede ser mejor incluir un hash con el nombre de configuración como la clave y el valor que el valor (escrito como objeto, pero eso abrirá otra lata de gusanos). Gracias por el aporte. –

0

El uso de nombres de columna para distinguir configuraciones suele ser una idea terrible. La entidad con la que está tratando es el AJUSTE, y tiene los atributos NOMBRE y VALOR. Si necesita usar el mismo nombre en diferentes contextos, establezca el AJUSTE jerárquico, es decir, cada configuración, excepto que la raíz obtiene un elemento primario. Sus clientes podrían tener la raíz como su padre, y la ruta debajo de cada cliente sería la misma para cada configuración. Puede usar diferentes columnas para tipos de datos adicionales si lo desea.

Cuestiones relacionadas