保存文件的通用机制的性能问题答案

【问题标题】：Performance concern for a generic mechanism of saving files保存文件的通用机制的性能问题
【发布时间】：2017-09-16 18:22:19
【问题描述】：

我想创建一个通用机制来在我的应用程序和数据库中保存文件，为此我想出了创建两个带有以下schema 的表的想法，以便保存与任何数据库中的任何行相关的文件表：

FileInfo
=================================================================
ID   FileName   ContentType   FileSize   DatabaseTableName  RowID

并使用OneToOne 关系创建下表以将文件数据保存在单独的表中，以便可以更快地查询FileInfo 表：

FileData
=================================================================
ID  FileData

好吧，我不是数据库性能方面的专家，这就是为什么我想知道这种将所有表的所有文件保存在一个表中的设计是否会导致性能问题？练习？

如果可以的话，您能否提供一个更好的解决方案？

提前致谢

【问题讨论】：

您是否尝试将文件数据存储在数据库中，如果是，我建议您查看 Filestream::docs.microsoft.com/en-us/sql/relational-databases/blob/…
@TheGameiswar 我想让用户配置文件是保存在数据库中还是作为文件系统保存。所以是的文件可能会保存在数据库中。
好的，有什么理由这样做I want to allow users to configure whether the files will be saved in database or as file system
@TheGameiswar 在我看来不是真的！我只想考虑用户的意愿……一些用户和数据库管理员可能更喜欢将文件保存在数据库中，而另一些用户和数据库管理员可能更喜欢将它们保存为系统文件。我关心的只是实现灵活和高性能的设计
恕我直言，用户不应决定应用程序应将其数据和文件存储在何处以及如何存储。他们通常不会理解选项并做出错误的选择。也就是说，SQL Server 不是文件服务器，因此在其中存储文件是一个好的解决方案的情况是有限的。

【解决方案1】：

我觉得没有论文就无法回答这个问题。基本上可以将文件存储在数据库中。数据库和文件系统具有截然不同的属性。值得称赞的是，您希望让您的框架的用户能够根据自己的情况选择正确的选择。

将其拆分为多个表（手动分区）或任何其他形式的分区都无济于事。 SQL Server 在处理超大表时没有固有的问题。

数据库中的 Blob 会导致一些特定的缺陷。这些 blob 住在哪里并不重要。

我喜欢你做的分成两张桌子。通常，这不是必需的。如果查询编写正确并且只提取需要的列，则 SQL Server 根本不会触及未使用的 blob 列。

也就是说，像您那样拆分大块通常很方便。 ORM 不喜欢大行。工具（以及运行简单手册 select * 的管理员）现在可以查看 FileInfo 表而不会因为数据量大而失败。

拆分不是必需的，但可以更轻松地使用数据库。

【讨论】：