我会选择MySQL数据库——因为它更容易管理。

JSON并不是一种真正的用于存储的格式，而是用于向JavaScript发送数据的。如果你想要把数据存储在文件中，可以考虑使用XML或者序列化的PHP（我猜你想要的是序列化而不是JSON）。

对于小型的、单用户数据库来说，文件系统可能更快-随着大小和复杂度的增加，像MySQL或SQL Server这样的数据库服务器是无法抵挡的。

我肯定会选择数据库选项（因为你需要能够搜索和索引内容）。但这并不意味着你需要一个完全实现的单独数据库服务。

MySQL is definitely the more scalable solution.
But the downside is you need to set up and maintain a separate service.

另一方面，还有基于文件的数据库，仍然可以使用标准的SQL访问（SQLite SQLite.org）是一个明显的例子。您可以获得SQL的优势，但不需要维护单独的服务。缺点是它们不如可扩展。

如果我的回答没有很明确地回答你的问题，请原谅，但由于这是一个家庭烹饪的博客系统，现在真的值得花时间考虑哪种存储后端更快吗？

从第一天起，您不会看到1万个并发用户，似乎在可预见的未来不需要扩展到任何有意义的程度。

为什么不坚持选择MySQL而不是快速的选择呢？如果你真的想要一些针对速度的设计感，可以考虑添加sqlite。

由于您认为您可能不需要一个复杂的关系结构，这可能是一个尝试更简单方法的有趣机会。

看看CouchDB，它是一个基于文档的，无模式的数据库（但仍然可以索引）。数据库由包含命名字段（类似键值对）的文档组成。

玩得开心... (wán dé kāi xīn...)

虽然我不能确定，但我认为MySQL数据库会更快，尤其是数据量越来越大时。

此外，使用MySQL和PHP非常容易，尤其是如果您使用像ezSQL这样的抽象类。 ezSQL使得与数据库的工作变得非常简单，我认为通过自己实现JSON方向，您将会为自己创造更多不必要的工作。

我两种都做过。我喜欢文件来解决非常简单的问题，而对于复杂的问题则喜欢使用数据库。

对于文件解决方案，请注意随文件数量增加而出现的问题：

使用的磁盘空间比您预期的要多得多，因为即使是微小的文件也会占用整个块。在支持大型驱动器的文件系统上，块相当大。

2) 大多数文件系统在一个目录下的文件数量变得非常大时会变得非常慢。我的解决方法是（假设文件名称在字母表中分布合理），创建一个由文件名前两个字母组成的目录。因此，“animal.txt”文件将在an/animal.txt中找到。这种方法效果惊人。如果你的文件名在字母表中分布不合理，可以使用某种哈希函数来创建目录。听起来有些疯狂，但这个方法可以非常快速地处理数以万计的文件，我已经用它来解决快速方案。

但是，文件解决方案只有在某些情况下才适用。除非您有很好的理由选择文件，否则请使用数据库。

这太酷了。这是一个使用查询控制平面文件数据库的PHP类。 http://www.fsql.org/index.php

对于博客，我建议缓存页面，因为博客通常只有静态内容。这样，在缓存时查询只运行一次。当添加新博客文章时，您可以更新缓存页面。