将大数据存储在文件与表中

Question

所以我正在研究website，人们可以发表文章。我的同事建议将文章(user, title, dates etc)的所有元数据存储在一个表中，将实际的文章正文存储为服务器中的文件。

数据结构如下：

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";

他说这会减少表格的大小，从长远来看，它可以更快地访问。我不确定这一点，并想问一下这个设计是否有任何问题。

Answer 1

我同意，在生产环境中，通常建议让文件系统跟踪文件和数据库以保留元数据。

但是，我大多听说这种理念适用于BLOG类型和图像。因为即使是大型文章也相对较小，TEXT数据类型就足够了，甚至可以根据需要更轻松地进行编辑，绘图和搜索。 \

（因此我同意RémiDelhaye的观点，就像我写这篇文章一样回答这个问题）

Answer 2

出现在我脑海中的第一个风险是数据损坏。在设计之后，您将将信息拆分为两个片段，即使两个片段彼此依赖：

• 每个元数据条目都必须存在一个文件（或者对于应该存在的条目，最终会出现 not found 错误。）
• 每个文件都必须存在元数据条目（否则最终会产生垃圾）。

使用数据库只有一个很大的优势：它很可能是关系。这意味着您实际上可以设置规则以防止上述两种情况发生（例如，您可以使用SQL CASCADE DELETE，或将每条信息放在一个表中）。在两个数据后端之间保持这些关系将是一个棘手的设置。

另一个要记住的重要事项：存储在SQL数据库中的数据不会发送到远离驱动器的神奇地方。在数据库中添加条目时，会写入数据库文件。例如，这些文件存储在/var/lib/mysql的MySQL引擎中。写入其他文件并没有太大的区别......

下一件事：时间。一旦打开数据库，访问数据库就很快，只需要查询处理。访问文件（即每篇文章一次）可能更重：需要打开文件（包括权限检查，...），读取（根据缓冲区大小逐行）并关闭。当然，您可以添加将这些文件链接到其元数据所需的所有编程...

对我而言，这种设计为应用程序增加了不必要的复杂性。您可以将所有内容存储在数据库中，集中。在这两种情况下，您将使用几乎相同数量的磁盘空间，但单独查找/访问每个文章文件（同时保持与其数据库元数据连接）肯定会浪费一些时间。

  

简约设计;只在必要的地方添加复杂性。 （Eric S. Raymond）

Answer 3

这可能看起来像好主意这些帖子从不编辑。访问文件可能需要一段时间，如果您的用户想要编辑很多次他的帖子，将内容存储在文件中并不是一个好主意。 SQL支持很大的文本值（如WYSIWYG文本），不要害怕将它们存储在Post表中。

此外，您的文件系统将花费更多时间来读取和写入存储在文件中的数据，而不是数据库。

所有内容都取决于您要存储的帖子数量，以及用户是否可以编辑或不他们的帖子。

Answer 4

文件系统更有可能具有更高的延迟，并且在数据库记录不太可能的情况下文件可能“丢失”。

如果SQL Server的字段内容太大，那么您可以查看较新版本的FileStream API。

实际上，在我看来，这两种方法都是有效的。使用文件，如果在转义期间出错，则不必担心数据库会破坏内容。

请注意，如果您在不区分大小写的文件系统上编写代码并在生产文件名中运行区分大小写的情况，那么它可能是以后失去对文件的访问权限的另一种方式已部署。