¿Está bien almacenar datos de presentación en la base de datos?

Question

Voy a mostrar las filas de una tabla de base de datos (SQL SERVER 2005) en una página web. Estas filas contienen un ID de estado (clave externa) que se define con más detalle por la tabla de estado (por ejemplo, id, name, modifiedDate).

Los diferentes estados deben mostrarse de forma diferente (digamos que simplemente tienen un color de fondo diferente).

Estoy usando php para consultar la base de datos y crear la tabla de la página web. A medida que construyo la tabla, voy a aplicar una clase css a un elemento en función del estado de esa fila.

que tener al menos 2 opciones para hacer esto:

1. Definir la lógica de código en el php para manejar la situación, y si los estados se cambian en la base de datos, que tendrá que cambiar el código.

2. Almacene la "clase" en la base de datos y simplemente aplique la clase que se ha almacenado.

La última opción me parece mejor, pero no estoy seguro de si incluir datos de presentación en la base de datos es una mala opción de diseño. Esta será la base sobre la cual creo varias utilidades de intranet, y me gustaría comenzar con el pie derecho.

Answer 1

No hay nada de malo en almacenar datos en la base de datos, incluidos los datos de presentación. Si le ayuda a producir resultados efectivos, mientras escribe menos código, entonces es una buena práctica. Lo que necesita asegurarse es que no mezcle su lógica de presentación con su lógica de base de datos.

Puede asegurarse de que estas preocupaciones se separen encapsulando los datos de su capa de presentación en las propiedades de un objeto elementInfo (por ejemplo).

Dado que es una clase CSS que se está hablando, estos datos presentación debe mantenerse separado de los datos de negocio . Entonces, aunque está bien almacenar datos de presentación y comerciales en la base de datos, no es aceptable almacenarlos en la misma tabla.

la actualización de nuevo: Comentario No, no habría que añadir el ID de un PresentationClassRecord como FK en el objeto de negocio. Hice una muestra de un enfoque para el DB a continuación. Llamé al DummyTable sus objetos comerciales, y el resto sigue las especificaciones. La parte más relevante es la StatusPresentationAssignmentTable

----------------------------------------------- 
DummyTable 
----------------------------------------------- 
Id  Name  SomeOtherDataField StatusId 
PK int varchar int     FK int 

----------------------------------------------- 
StatusTable 
----------------------------------------------- 
Id  Name  ModifiedDate 
PK int varchar datetime 

----------------------------------------------- 
PresentationTable 
----------------------------------------------- 
Id  PresentationType Value 
PK int varchar    
sample data: 
43  CssClass   prettyBackground 

----------------------------------------------- 
StatusPresentationAssignmentTable 
----------------------------------------------- 
StatusId PresentationId 
FK int  FK int 

Ahora, con dos simples unirse a las cláusulas, usted puede obtener los datos de presentación y que esté completamente desacoplado de datos de su empresa. Su secuencia de comandos podría hacer algo así como comprobar si el estado del maniquí tiene asignaciones de presentación. Si lo hace, mira el PresentationType, obtiene la función apropiada para aplicar los datos de presentación a la presentación y la ejecuta. (Debería tener una función para cada PresentationType que sepa cómo manejar el valor, algo que podría ser encapsulado por algo como function applyPresentationValue(presentationElement, presentationType, presentationValue) que llama a una función diferente applyCssClass(presentationElement, value) si es presentationType == "CssClass").

Answer 2

La clase en sí no es realmente datos de presentación. Es solo una etiqueta para cada tipo de estado. Podría, en teoría, usarlo para muchas cosas además de decidir de qué color debe ser el estado cuando aparece en una página web.

Cuando combina esa clase con un conjunto de estilos determinado, y luego es información de presentación. Y lo harás en tu archivo CSS, no en la base de datos.

Sin embargo, la opción 1 no requiere necesariamente que cambie su código PHP si cambian los estados en la base de datos. Su PHP podría simplemente generar el nombre de clase a partir del id o name del estado. Su CSS debería cambiar si la identificación/nombre de un estado cambió, ¿pero es probable? ¿No debería cada estado permanecer constante, con nuevos estados agregados, si hay cambios en los estados que la aplicación necesita representar?

Answer 3

Veo las ventajas y desventajas de almacenar esto en la base de datos. Obviamente, es conveniente tener la información de la clase allí, pero en realidad no es parte de la aplicación.

Me inclino por no almacenarlo allí y hacer algo en la capa de presentación para manejarlo en función del estado. Mi razonamiento se debe a que, especialmente desde que está creando utilidades, los datos pueden usarse a través de una API o algo más adelante, donde la clase no tiene sentido.

Answer 4

Si bien puede almacenar la información de la clase css en la base de datos, muchos sistemas de administración de contenido hacen esto, probablemente sea mejor que el estado forme parte del nombre de clase. estado

es decir = abierto, cerrado lógica de usar PHP para generar las filas de la tabla y establecer la clase CSS a Status_ {nombre} continuación, cada vez que añada un nuevo estado o cambiarle el nombre es suficiente con añadir/editar el archivo css, no se requiere una grabación de php.

.status_open{background-color:green;}

.status_closed{background-color:red;}