在处理用户输入的标记（例如 wiki 或 Markdown）时，任何对您有用的建议。 我有CPU和 数据库空间成本，所以我不确定该走哪条路。
-
将标记存储在数据库中 渲染到
服务器上每个浏览量的 html。 （数据库空间更少，但 CPU 使用率更高）
-
将标记存储在数据库中 渲染到
使用 javascript 在客户端上生成 html。 （可能更难实现）
-
仅将渲染的 html 存储在
数据库与 转换回标记如果
需要编辑。 （同样，实现起来可能很棘手）。
-
同时存储 html 和 html 中的标记
数据库。 （数据库空间加倍）。
-
别的东西。
（我正在使用 MFC 和 Linqtosql）。
Any advice what has worked for you when dealing with user-entered markup, e.g. wiki or markdown. I have both CPU & database space costs, so I'm not sure which way to go.
-
Store markup in database & render to
html on the server for each pageview. (Less database space but more CPU usage)
-
Store markup in database & render to
html on the client using javascript. (Possibly more difficult to implement)
-
Store just the rendered html in the
database & convert back to markup if
editing required. (Again, possibly tricky to implement).
-
Store both html & markup in the
database. (Double the database space).
-
Something else.
(I'm using MFC & Linqtosql).
发布评论
评论（4）
我会将其作为 Wiki 标记存储在数据库中，然后将转换后的 HTML 输出保存在网络服务器上的缓存中。 无论您使用哪种网络技术，都应该支持这一点 - 以 url、id 或类似内容为键的基本元组（哈希表）。
I would store it in the database as Wiki markup, then hold the transformed HTML output in memory in a cache on the webserver. Whichever web technology you're using, all should support this - a basic tuple (hashtable) keyed on the url, or id, or similar.
我会动态存储标记并渲染 html 服务器端。 您可以使用服务器端缓存来减少执行的实际计算量，并且可以保留具有合理语义的表示形式，并且可以根据需要呈现为 text/html/pdf。
I would store the markup and render html server side on the fly. You can use server side caching to reduce the amount of actual computation you perform and you get to keep a representation that has reasonable semantics and can be rendered to text/html/pdf if needed.
最简单的方法是存储标记并根据渲染时间戳在缓存中（可能在磁盘上或在 memcached 对象中）按需渲染 HTML。 这样您就可以检查是否需要再次渲染，因为标记已更改，或者只是提供缓存的 HTML。 这就是大多数 Ruby on Rails 应用程序/CMS 的工作方式。
Easiest way would be to store markup and render the HTML on demand in a cache (possible on disk or in memcached onjects) with the timestamp of render. That way you can check whether you need to render again because the markup has changed or just serve the cached HTML. That is the way most Ruby on Rails apps/CMS work.
我会将其作为 RST 标记存储在数据库中，并根据需要转换为 HTML。 由于您可能使用前端（例如 JSP、PHP、Django 或其他呈现模板语言的语言），因此 RST 的额外处理不会带来太多开销。
在决定实现复杂的缓存机制之前，实际测量将标记呈现为 HTML 的实际开销。
“（更少的数据库空间，但更多的 CPU 使用率）”不是一个衡量的事实，而是一个可能被证明是不正确的假设。
I would store it in the database as RST markup, and transform to HTML as needed. Since you're probably using a front-end (e.g. JSP, PHP, Django or something else that renders a template language) the additional processing for RST won't introduce much overhead.
Actually measure the actual overhead of rendering the markup into HTML before deciding to implement a complex caching mechanism.
The "(Less database space but more CPU usage)" isn't a measured fact, it's an assumption that may turn out to be not true.