将文件(图片)存储在网站的SQL Server中的Pro&Cons

Question

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

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

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

它有几个优点:

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

但它也有一些缺点:

• 有一些大文件(它是少数,但它会发生),如100-200MB,我不确定在数据库中有这种文件是好的吗？(这更像是一个问题;))
• 我不确定它会有不错的表现吗？

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

Answer 1

微软研究院发表了一篇非常好的论文,名为To Blob或Not To Blob.

经过大量的性能测试和分析,他们的结论如下:

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

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

• 在这两者之间,根据您的使用情况,这有点偏僻

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

对于文件组,请查看文件和文件组体系结构以获取介绍.基本上,您可以从一开始就为大型数据结构创建具有单独文件组的数据库,或者稍后添加其他文件组.我们称之为"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简介,并使用它!