我正在帮助某人更新他们的网站，我们正在考虑从当前基于MySQL的内容管理系统转变为平面文件系统。该网站包含大约十个静态页面，然后是一个每周最多更新一次的博客。
假设有假设，如果总共只有十个博客页面，那么它足够快且足够高效，可以将每个博客页面保存为自己的PHP页面，并且每个文件中都需要任何元数据。如果您想按类别显示页面列表，每个页面都有图标图像，您可以只包括每个页面，将必要的数据放入数组中，然后执行任何操作。
但实际上，在每周一个新页面上，假设博客长寿并持续十年，那就是520页。在那种卷上，我想知道是否只是将每个博客条目存储为具有自己的元数据的自己的页面。数据库中的520个条目都不算什么。文件系统中的520个条目对于PHP系统来说过于繁琐吗？
我是否正确，520个文件及其中的信息太多，无法在PHP系统的合理时间内加载（定义用户等待页面加载的时间长度）？
我应该考虑哪些参数来衡量使用数据库而不是加载文件更有意义的截止点？
忽略设计并回答您的问题：
520静态文件什么都没有。
系统将处理它很好。
如果文件系统访问速度有问题，那么你可以简单地将文件缓存在RAM中，这使得这个问题没有实际意义。
搜索，你没有提到，将是一个不同的问题，数据库是值得的 - 即使从少量的记录。
如果您所做的只是通过它的名称访问该文件，那么文件系统可以容纳大量文件而不会出现问题。具体数字归结为inode限额和特定文件系统。
这可能被归类为意见问题，因此可能会被标记为关闭。
静态文件总是比数据库快，无论它们有多少。只要您的内容不是基于用户/日期/等的动态，那么您应该走这条路。
我认为你将面临的主要问题是文件可以被意外删除和PHP删除。
如果有两个用户同时访问同一个文件，则代码将无法再次打开该文件并返回false。
如果你使用具有读写功能的file()，这将使file()创建文件，覆盖原始文件。
如果你使用file_get_contents()我认为你会更安全，但它仍然可以返回false文件不存在。