我应该将存储的 Markdown 转换为 HTML，还是应该只存储 HTML？答案

【问题标题】：Should I convert stored Markdown to HTML, or should I just store HTML?我应该将存储的 Markdown 转换为 HTML，还是应该只存储 HTML？
【发布时间】：2012-05-14 11:24:09
【问题描述】：

Markdown 似乎比 HTML 更容易编写和编辑。我见过的所有 HTML 编辑器都会输出大量不必要的垃圾。 Markdown 看起来更干净。

这是我正在考虑做的事情：将 markdown 存储在数据库中，使用PHP Markdown 将其转换为 HTML，然后将其输出到 Web 浏览器。

一个问题是它必须这样做每次页面被请求。这似乎有点贵。

这是个好主意吗？还是有更有效的方法来做到这一点？

【问题讨论】：

标签： php markdown

【解决方案1】：

作为一个实际示例，Stack Overflow 支持 Markdown（如您所知），但将 Markdown 和呈现的 HTML 都存储在数据库中。这使得提供页面的速度更快，因为呈现的 HTML 总是相同的。帖子的创建频率远低于向用户显示的频率。

【讨论】：

这正是我的想法。如果您存储降价，则必须在每个页面加载时进行解析。如果您解析和存储 html，您将获得更快的页面加载速度，但几乎无法编辑。存储两者（比特很便宜）可以两全其美。
作为替代方案，您还可以缓存转换后的 HTML，限制对 DB 的访问和存储它的需要。当然，这取决于您的应用程序:)

【解决方案2】：

远离您的网站，问问自己它到底有多“昂贵”。您每天为超过 1,000 个唯一身份提供服务吗？实际上，它会膨胀吗？对于所有这些类型的问题，答案并不明确。例如，当我为一家国际银行构建网站时，一个非最小化的 CSS 文档每天可以增加 1 GB 的带宽。但是，当我在构建我的投资组合网站时，我预计流量只是其中的一小部分。

我当然不是提倡构建低效的代码....请记住，“成本”实际上应该以流程时间执行来衡量，而不仅仅是流程。

如果您真的很担心，请记录 PHP Markdown 流程执行前后的时间。然后，以 A/B 方式跟踪一段时间的服务器负载。数字不会说谎。

【讨论】：

对不起，如果这听起来很傻……记录什么？带宽？请求前后的磁盘空间？
@BountyMan，编码中的一种常见做法是在操作之前和之后回显（或记录）时间戳。这样，您就可以知道完成特定功能需要多长时间。在 UI 开发中，您通常可以跳过这一步，只使用浏览器的诊断工具，但在 PHP 等后端语言中，似乎最简单的方法就是输入两个时间戳并从那里开始工作。

【解决方案3】：

我最近完成了一个与您所要求的非常相似的项目。我没有将完整的 HTML 存储在数据库中，而是选择使用专有 API 将标记过的 html 存储在文件系统上，就像 MongoDB 一样。降价存储与全面存储的美妙之处在于文件系统上的足迹要小得多，如果您需要查看原始降价，它更容易阅读。当用户编辑 html 时，我会渲染完整的内容，以便他们可以看到它的样子。

还有其他存储两者的建议，我不太同意。如果您希望通过不必为每个请求标记降级版本来提高性能，那么我会考虑在每次编辑时缓存完整版本。同时存储降价和全面存储违背了降价的目的，因为您要付出磁盘空间和/或数据库操作的代价。

【讨论】：

同意这一点，两者都存储似乎没用。感觉MD根本不应该用

【解决方案4】：

您可以同时存储两者。如果必须多次编辑存储的 Markdown，或者如果开发了另一个或更好的 Markdown 到 HTML 翻译，则存储的 Markdown 很有用。正如您所说，存储的 HTML 很有用，可以避免一次又一次地重新生成它。

【讨论】：