我正在分析一个具有常规会计操作和数据以及客户关系管理（CRM）的系统。在系统的CRM部分，我们记录客户的通话并将其保存在某个地方，我们可能会保存客户的图片，徽标，签名，扫描的文档等。所以我们应该处理各种各样的文件（声音、图像、pdf、Word 文档等......
我需要帮助决定文件保存位置。
在旧系统中，我们将文件保存在硬盘驱动器空间上并保存数据库的路径，在需要时，我们将使用它地址打开文件。我认为（如果我错了，请纠正我）将文件保存在 HDD 上不是一个好的解决方案，因为：
-
我们失去了数据完整性。文件名可能会因任何原因而更改（重命名、移动、删除、覆盖），从而导致数据库中的路径错误。
移动 整个数据（移动服务器）将是一个耗时的过程，假设我们有 1,000,000 个文件，总共达到 20 GB。如果我想将 100 万个文件从一台计算机移动到另一台计算机，假设我的 PC 确实可以容忍它并且不刻录，则移动文件需要很长时间（复制大量小文件的 I/O 时间比复制大文件的时间多），但移动 20 GB 数据的单个文件（数据库文件）会快得多。
与复制文件相比，备份数据库中的数据更容易。使用完整备份和差异备份，我们可以一次备份数据的正确部分，也可以为此制定定期计划。
也许还有其他原因...
我的问题在这里。
-
在数据库中存储文件并增加数据库是否会感染常规数据库操作？比如选择、更新、查询表等。我的意思是，如果我将文件（CRM数据）存储在同一个数据库中（与会计数据一样），我的会计系统会变慢吗？
-
我应该在哪里保存文件？在普通表中？或者我应该将数据库分成两个文件？一个用于典型数据，一个用于文件？
-
Sql Server 2012 是否有空间限制？如果我的文件部分在数据库增长，例如达到 500 GB（假设磁盘驱动器有足够的空间），SQL Server 会处理它吗？
-
使用数据库存储文件可能有哪些缺点？我刚刚谈到了优点，可能有缺点。如果有，它们是什么？
Microsoft Research有一篇非常好的论文，叫做To Blob or 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 介绍，并试用它！
> 我建议您检查SQL Server 2012中的FILETABLE功能：
http://technet.microsoft.com/en-us/library/ff929144.aspx
除非您通常处理非常小的文件，否则您可能会获得更好的性能。无论如何，我几乎总是会用一点性能来换取一致性。
使用FILETABLE，文件存储在文件系统中，但由SQL Server进行事务管理。因此，您可以两全其美 - 完整性、统一的安全性和管理、易于编程访问，甚至性能。