Sql 数据库分析，文件应该去哪里？答案

【问题标题】：Sql Database analyse, where should files go?Sql 数据库分析，文件应该去哪里？
【发布时间】：2014-04-04 15:11:00
【问题描述】：

我正在分析一个具有日常会计操作和数据以及客户关系管理 (CRM) 的系统。在系统的 CRM 部分，我们记录客户的电话并将其保存在某个地方，我们可能会保存客户的图片、徽标、签名、扫描文档等。所以我们应该处理范围广泛的文件（声音、图像、pdf、word 文档等......）

我需要帮助来决定将文件保存在哪里。

在旧系统中，我们将文件保存在硬盘驱动器空间并保存到数据库的路径，并在需要时使用它的地址打开文件。我认为（如果我错了，请纠正我）将文件保存在 HDD 上并不是一个好的解决方案，因为：

我们失去了数据完整性。文件名可能因任何原因被更改（重命名、移动、删除、覆盖），从而导致数据库中的路径错误。
移动整个数据（移动服务器）将是一个耗时的过程，假设我们有 1,000,000 个文件，总共达到 20 GB。如果我想将 100 万个文件从一台计算机移动到另一台计算机，假设我的 PC 确实容忍它并且不刻录，那么移动文件将需要很长时间（复制大量小文件的 I/O 时间超过复制一个大文件）但移动一个 20 GB 数据的单个文件（数据库文件）会快得多。
与复制文件相比，备份数据库中的数据更容易。使用完全备份和差异备份，我们可以一次备份正确的数据部分，我们也可以为我们制定一个定期的计划。

也许还有其他原因......

我的问题来了。

在 db 中存储文件并增加 db 是否会影响常规 db 操作？像选择、更新、查询表等等。我的意思是如果我将文件（CRM 数据）存储在同一个数据库中（对于会计数据），我的会计系统会变慢吗？
我应该将文件保存在哪里？在普通的桌子上？或者我应该将数据库分成两个文件？一个用于典型数据，一个用于文件？
Sql Server 2012 有空间限制吗？如果我的 db 文件部分增长，例如达到 500 GB（假设磁盘驱动器有足够的空间），Sql Server 会处理它吗？
使用数据库存储文件有什么缺点？我刚刚谈到了优点，可能有缺点。如果有，它们是什么？

【问题讨论】：

根据 SQL Server 2012 的Maximum Capacity Specifications，最大。文件大小为 16 TB - 您的数据库可以有多个文件。够好吗？
@marc_s 感谢您的回答，但我应该像其他数据一样将文件保存在数据库中，还是将我的数据库分成两个文件并将文件与其他数据分开？它会影响其他数据吗？有什么缺点？

标签： sql-server database file database-design file-io

【解决方案1】：

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

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

如果您的图片或文档的大小通常低于 256K，则将它们存储在数据库中的 VARBINARY 列中会更有效
在这两者之间，根据你的使用情况有点折腾

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

对于文件组，请查看Files and Filegroup Architecture 了解简介。基本上，您可以从一开始就为大型数据结构创建带有单独文件组的数据库，或者稍后添加一个额外的文件组。我们称之为“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 介绍，并尝试使用它！

【讨论】：

LOB 数据已经在行外存储了，我不明白单独放置员工图片如何提高效率（除非你有做 SELECT * 的习惯）。你有两种方式的指针开销。管理问题是更有效的论据 imnsho。
FileStream 在这里很棒，因为您确实获得了优势 - 参照完整性和......制作连贯的备份。 +1 - 了解这个大多数人似乎更愿意忽略的功能。

【解决方案2】：

我建议您检查 SQL Server 2012 中的 FILETABLE 功能：

http://technet.microsoft.com/en-us/library/ff929144.aspx

除非您通常处理非常小的文件，否则您可能会获得更好的性能。无论如何，我几乎总是会牺牲一些性能来换取一致性。

使用 FILETABLE，文件存储在文件系统中，但由 SQL Server 以事务方式管理。因此，您可以获得两全其美 - 完整性、统一的安全性和管理、易于编程访问，甚至性能。

【讨论】：