Almacenamiento de datos para tablas HTML en la database

Estoy desarrollando una aplicación que usa PHP / SQL Server que necesita almacenar información sobre graduados de toneladas de diferentes progtwigs académicos, junto con información sobre cuántos estaban empleados después de graduarse … Esto luego será consultado por los usuarios, quienes querrán comparar un progtwig con otro, por lo que deberán ser capaces de generar tablas personalizadas que muestren los resultados para los estudiantes. Las tablas serán algo como esto:

Program Salary after 1 Year Salary after 2 Years Etc... Engineering Lots Even more! Philosophy Nothing Are you kidding me? 

Entonces, aquí está la pregunta: ¿debo almacenar valores individuales para estos puntos de datos en la database, o debería simplemente almacenar el HTML sin formatting para la fila de la tabla?

En otras palabras, ¿guardo esto?

 ProgramID Salary1 Salary2 Etc... 1 Lots Even More! 2 Nothing Are you kidding me? 

¿O guardo esto?

 ProgramID RowHTML 1 <td>Lots</td><td>Even More!</td>... 2 <td>Nothing</td><td>Are you kidding me?</td> 

Puedo ver arguments para ambos enfoques … mi intuición me dice que almacenar el HTML sin procesar será más rápido: eliminará los GOBS del procesamiento de PHP. Pero estoy abierto a otras interpretaciones.

Regla simple para cualquier RDBMS, solo almacene los datos en sus tablas y nada más.

Esto hará que su recuperación de datos, actualización e inserción de operaciones sea rápida, simple y segura. Almacene datos en sus tablas y cree tablas HTML en time de ejecución. He demostrado aquí lo fácil y simple que es crear tablas HTML cuando solo tiene datos almacenados en su tabla y nada más.

Ejemplo

He usado tu ejemplo dado

 DECLARE @t TABLE (ProgramID INT,Salary1 VARCHAR(50),Salary2 VARCHAR(50)) INSERT INTO @t VALUES (1,'Lots','Even More!'), (2,'Nothing','Are you kidding me?') DECLARE @tableHTML NVARCHAR(MAX) ; SET @tableHTML = N'<H1>Students Salaries</H1>' + N'<table border="1">' + N'<tr><th>ProgramID </th><th>Salary1</th><th>Salary2</th>' + CAST ( ( SELECT td = ProgramID, '', td = Salary1, '', td = Salary2 FROM @t FOR XML PATH('tr'), TYPE ) AS NVARCHAR(MAX) ) + N'</table>' ; SELECT @tableHTML; 

Tabla HTML creada por la consulta anterior

<H1>Students Salaries</H1><table border="1"><tr><th>ProgramID </th><th>Salary1</th><th>Salary2</th><tr><td>1</td><td>Lots</td><td>Even More!</td></tr><tr><td>2</td><td>Nothing</td><td>Are you kidding me?</td></tr></table>

Almacenaría los datos brutos solamente. esto proporcionará la capacidad de cambiar el formatting / layout de la página cuando su jefe dice "Haz que se vea más nuevo" o lo que sea. Si almacena los datos de la tabla, está atascado.

Creo que almacenar valores individuales para estos puntos de datos en la database será mejor para administrar la aplicación, HTML es bueno, pero cuando trabajas con PHP-DATAbase es mejor, … buena suerte amigo.

Entonces, aquí está la pregunta: ¿debo almacenar valores individuales para estos puntos de datos en la database, o debería simplemente almacenar el HTML sin formatting para la fila de la tabla?

Respuesta directa:

Almacene los data points , el html que siempre puede volver a crear más adelante, esto también hará que sus consultas sean mucho más rápidas.

Respuesta corta: almacene los datos individuales, no el HTML.

No hay ningún beneficio para almacenar HTML aquí. Reproducir la tabla puede ser un poco más fácil, pero también está almacenando mucha información networkingundante, y build tablas dinámicamente no es una tarea difícil para empezar. También es mucho más fácil manipular datos sin procesar: cuando almacena salarios a lo largo del time como una sola fila de HTML, solo puede orderar por progtwig, pero si almacena cada año individualmente y controla el tipo de datos (sus salarios de ejemplo son cadenas de caracteres). , pero debe almacenar integers o flotadores, ya que sabe que el salario es una cantidad de dinero), tiene la opción de clasificar los progtwigs por cuánto dinero ganan los egresados ​​de la universidad, diez años después, etc. Tenga en count que es posible que no siempre desee mostrar una tabla: es posible que desee graficar los ingresos a lo largo del time para cada especialización, por ejemplo, en cuyo caso necesitaría extraer los salarios de las tags y, creando más trabajo para usted y ralentizando la aplicación.