Renderizar marcado sobre la marcha o almacenar html?

Question

Cualquier consejo sobre lo que ha funcionado para usted cuando se trata de un marcado introducido por el usuario, p. wiki o markdown. Tengo tanto CPU y amp; costos de espacio de la base de datos, así que no estoy seguro de qué camino tomar.

1. Almacenar marcado en la base de datos & amp; rendir a html en el servidor para cada página vista. (Menos espacio en la base de datos pero más uso de la CPU)

2. Almacenar marcado en la base de datos & amp; rendir a html en el cliente usando javascript. (Posiblemente más difícil de implementar)

3. Almacene solo el html representado en el base de datos & amp; convertir de nuevo a marcado si Se requiere edición. (De nuevo, posiblemente difícil de implementar).

4. Almacene tanto html & amp; marcado en el base de datos. (Duplica el espacio de la base de datos).

5. Algo más.

(estoy usando MFC & amp; Linqtosql).

Answer 1

Lo almacenaría en la base de datos como marcado Wiki, luego guardaría la salida HTML transformada en la memoria en un caché en el servidor web. Independientemente de la tecnología web que esté utilizando, todos deberían admitir esto: una tupla básica (tabla hash) tecleada en la url, o id, o similar.

Answer 2

Almacenaría el marcado y renderizaría el lado del servidor html sobre la marcha. Puede usar el almacenamiento en caché del lado del servidor para reducir la cantidad de cómputo real que realiza y puede mantener una representación que tenga una semántica razonable y se puede representar en texto / html / pdf si es necesario.

Answer 3

La forma más fácil sería almacenar el marcado y renderizar el HTML a pedido en un caché (posible en disco o en proyectos de memoria caché) con la marca de tiempo de renderizado. De esa manera, puede verificar si necesita renderizar nuevamente porque el marcado ha cambiado o simplemente sirve el HTML en caché. Esa es la forma en que funcionan la mayoría de las aplicaciones / CMS de Ruby on Rails.

Answer 4

Lo almacenaría en la base de datos como marcado RST y lo transformaría a HTML según sea necesario. Dado que probablemente esté utilizando un front-end (por ejemplo, JSP, PHP, Django u otra cosa que represente un lenguaje de plantilla), el procesamiento adicional para RST no introducirá mucha sobrecarga.

Mida realmente la sobrecarga real de representar el marcado en HTML antes de decidir implementar un mecanismo de almacenamiento en caché complejo.

El " (Menos espacio en la base de datos pero más uso de CPU) " no es un hecho medido, es una suposición que puede resultar ser falsa.