所以我正在开发这个网站，人们可以在其中发布文章。我的同事建议将文章的所有元数据(用户、标题、日期等)存储在表中，并将实际的文章正文作为文件存储在服务器中。
数据结构如下所示:
post_id post_user_id post_title post_body post_date etc
-------------------------------------------------------------------------------
1 1 My First Post 1_1.txt 2014-07-07 ...
2 1 My First Post 2_1.txt 2014-07-07 ...
--------------------------------------------------------------------------------
现在我们将获取帖子的记录，然后通过
定位它的位置$post_id . "_" . $post_user_id . ".txt";
他说，这将减少表的大小，从长远来看，可以加快访问速度。我对此不太确定，想问一下这个设计是否有问题。
最佳答案
我想到的第一个风险是数据损坏。按照设计，您将信息分割为两个片段，即使这两部分相互依赖:
- 每个元数据条目都必须存在一个文件(否则您最终会遇到本应存在的条目的未找到错误)。
- 每个文件都必须存在元数据条目(否则最终会得到垃圾)。
使用数据库只有一个很大的优点:它很可能是关系型的。这意味着您实际上可以设置规则来防止上述两种情况发生(例如，您可以使用 SQL CASCADE DELETE，或者将每条信息放入一个 table )。在两个数据后端之间保持这些关系将是一件棘手的事情。
要记住的另一件重要事情:存储在 SQL 数据库中的数据不会发送到远离驱动器的神奇位置。当您向数据库添加条目时，您将写入数据库文件。例如，这些文件存储在 MySQL 引擎的 /var/lib/mysql 中。写入其他文件并没有多大区别...
接下来的事情:时间。数据库打开后访问速度很快，所需的只是查询处理。访问文件(即每篇文章一次)可能会比较繁重:文件需要打开(包括权限检查等)、读取(根据缓冲区大小逐行)和关闭。当然，您可以添加将这些文件链接到其元数据所需的所有编程...
对我来说，这种设计给应用程序增加了不必要的复杂性。您可以将所有内容存储在数据库中，集中。在这两种情况下，您将使用几乎相同数量的磁盘空间，但单独查找/访问每个文章文件(同时保持其与其数据库元数据连接)肯定会浪费一些时间。
Design for simplicity; add complexity only where you must. (Eric S. Raymond)
关于php - 在文件中存储大数据与在表中存储大数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24657715/