2

我正在创建一个 Asp.Net MVC 网站。

我过去，对于繁重的应用程序，多层应用程序，使用数据库来存储文件。

但现在我在质疑自己，这对网站来说是个好主意吗？在性能视图中？

它对我有几个优点：

  • 允许我轻松控制连接的用户是否有权显示图像（我的项目需要）
  • 允许确保我们有一致的数据（否则我们可以有一个现有文件但数据库中没有信息，反之亦然
  • 我需要一个故障转移网络服务器，这些文件将从第三台服务器导入，所以如果这些文件在数据库中，我只需要在故障转移服务器上有一个工作的 ASP.Net 网站和一个复制的数据库，不需要同步文件。

但它也有一些缺点：

  • 有一些大文件（这是少数，但它会发生），比如 100-200MB，我不确定在数据库中有这种文件好不好？（这更像是一个问题；））
  • 不知道会不会有好的表现？

你怎么看？这合理吗？我在互联网上搜索，但我没有找到网站的一些参数。我的问题主要是关于 FILESTREAM VS FILESYSTEM，我确定 FileStream 速度较慢，但​​很多吗？因为如果它只是百分之几，那么功能的获得是值得的。

4

3 回答 3

7

Microsoft Research 有一篇非常好的论文，名为To Blob 或 Not To Blob。

他们经过大量的性能测试和分析后得出的结论是：

  • 如果您的图片或文档的大小通常低于 256K，则将它们存储在数据库的 VARBINARY 列中会更有效

  • 如果您的图片或文档的大小通常超过 1 MB，则将它们存储在文件系统中会更有效（并且使用 SQL Server 2008 的 FILESTREAM 属性，它们仍处于事务控制之下并且是数据库的一部分）

  • 在这两者之间，根据您的使用情况，这有点折腾

如果您决定将图片放入 SQL Server 表中，我强烈建议您使用单独的表来存储这些图片 - 不要将员工照片存储在员工表中 - 将它们保存在单独的表中。这样一来，Employee 表可以保持精简、平均和非常高效，假设您并不总是需要选择员工照片作为查询的一部分。

对于文件组，请查看文件和文件组架构以获得介绍。基本上，您可以从一开始就为大型数据结构创建带有单独文件组的数据库，或者稍后添加一个额外的文件组。我们称之为“LARGE_DATA”。

现在，每当您要创建一个需要存储 VARCHAR(MAX) 或 VARBINARY(MAX) 列的新表时，您都可以为大数据指定此文件组：

 CREATE TABLE dbo.YourTable
     (....... define the fields here ......)
     ON Data                   -- the basic "Data" filegroup for the regular data
     TEXTIMAGE_ON LARGE_DATA   -- the filegroup for large chunks of data

查看有关文件组的 MSDN 介绍，并尝试使用它！

于 2012-01-05T08:30:55.657 回答
4

如果文件是完整的并且是系统的主动更改部分，并且必须与其他数据一起备份 - 您可以将它们存储在数据库中，但如果您使用 sql server 2005+ 和您的文件，请尝试使用 FILESTREAM 字段足够大 - 比如说 500k+

如果文件是静态内容，您可以将它们存储在外部，只在数据库中使用指针。这并不妨碍考虑到您的所有自定义权限机器。

在 DB 中存储和处理文件通常比在文件系统中慢，但这完全取决于您的需要。

于 2012-01-05T07:56:24.210 回答
3

为什么使用 db 而不是 txt 文件？因为它使用索引更快。将整个文件存储在 db 中从来都不是一个好习惯。使用 db 作为正常 img 文件的索引（指针）。

就您的优点/缺点而言：

于 2012-01-05T08:00:20.417 回答