将帖子主体存储在数据库或文件中？

Question

我正在通过自己写博客来学习以网络为中心的编程，使用PHP和MySQL数据库后端。这应该取代我目前的（基于Drupal）博客。

我已经确定post应包含一些数据：id，userID，title，content，time-posted。这为数据库表创建了一个很好的模式。不过，我在决定如何组织content的存储时遇到了问题。

我可以：

1. 使用基于文件的系统。然后，数据库表content将成为本地文件的URL，然后我将读取，格式化和显示该文件。
2. 将帖子的全部内容存储在content中，即将其放入数据库。

如果我选择（1），搜索帖子的内容会有些问题 - 我只能进行元数据搜索，或者在搜索时我必须阅读每个文件的内容（尽管我不这样做）知道有多少问题 - grep -ir "string" .不是太慢......）。但是，图像（如果有的话）将由URL引用，因此引用content至少是内部一致的方法，并且我很容易能够重用内容，如与SQL数据库文件相比，文本文件非常容易使用。

与（2）一起，我可以使用longtext。然后在尝试将其放入元组之前需要对content进行消毒处理，并且我受到大小的限制（尽管我不太可能写一篇4GB的博客文章;）。搜索会很容易。

我（目前）没有看到哪种方式（a）更容易实现，（b）更容易实现。

我应该走哪条路/通常如何做？任何（1）或（2）的利弊都将受到赞赏。

Answer 1

对于“当前一代”，实施数据库几乎是你最安全的选择。正如你所提到的，它非常标准，你概述了所有有趣的东西。大多数SQL实例都具有相当强大的FULLTEXT（或等效）搜索。 您可能会在您概述的两者之间编写尽可能多的架构，特别是如果您希望其中一个具有另一个的功能奇偶校验。

即将推出的技术是一种键/值存储，通常称为NoSQL。通过这种方式，您可以将内容和元数据存储到单独的单个文档中，但结构化的方式可以使搜索和检索速度非常快。一些常见的NoSQL引擎是mongo，CouchDB和redis（以及其他）。

最终，这取决于个人偏好，以及一些用例考虑因素。在便利性和应用方面，您没有真正概述对您来说重要的事项。这些中的任何一个都适用于个人或开发博客。构建一个包含多个贡献者的整个平台是一个不同的对话。

Answer 2

13年前，我尝试过你的选项1（包含文本内容的外部文件） - 不是博客，而是CMS。最后我把它全部铲回数据库以便于处理。在数据库上进行全局替换比在文本文件级别上更容易。有大量的帖子你会遇到目录大小和访问速度的问题，或者你必须管理子目录方案等。坚持只使用数据库方法 - 有一些工具可以让你的文本文件比内置的mysql函数更容易，但是使用mysql和mysqldump之类的命令行客户端，你可以轻松地将任何文本提取到文件系统级别，使用标准工具处理它们并重新使用 - 将它们加载到数据库中。 mysql真正缺少的是对正则表达式搜索/替换的内置支持，但即便如此，如果你愿意重新编译mysql，你也会找到补丁。