考虑到在文件服务器上还是在DB中存储文档的位置？

Question

我有一个关于上传到网站的文档的设计决定：我可以将它们存储在文件服务器上的某个地方，或者可以将它们存储在数据库中（MSSQL 2005）。如果对设计决定有任何影响，这些文件是机密的，必须具有一定程度的保护。

我想到的考虑因素是：

1. 在文件服务器上存储使所有倾倒在单个目录中的文件数量，因此访问速度较慢，除非我可以为目录树结构找到合理的语义定义
2. OTOH，我猜该文件服务器可以比DB更好地处理压缩……还是我错了？
3. 我的直觉告诉我，数据库的安全性比文件服务器的安全性强，但我不确定这是否一定是正确的。
4. 不知道我的DB中有斑点会如何影响性能。

我非常感谢这里的一些建议。谢谢！

Answer 1

在SQL Server 2005中，您只能选择使用 VARBINARY(MAX) 将文件存储在数据库表中，或者将它们保存在外面。

将它们留在数据库之外的明显缺点是数据库无法真正控制它们发生的事情。他们可能会被移动，更名，删除.....

SQL Server 2008 介绍 FILESTERAM 属性打开 VARBINARY(MAX) 类型，使您可以将文件放在数据库表之外，但仍在数据库的交易控制下 - 例如，您不能仅从磁盘中删除文件，文件是数据库不可或缺的一部分，因此可以复制和备份。它。如果需要的话，太好了，但是它可能会带来一些巨大的备份！ :-)

SQL Server 2008启动提出了一些“最佳实践”，以直接在数据库中以及何时使用FileStream中存储东西。这些是：

• 如果文件通常小于256 kb，则数据库表是最佳选择
• 如果这些文件通常大小超过1 MB，或者大小可能超过2 GB，则FileStream（或您的情况下：普通的旧文件系统）是您的最佳选择
• 这两个边距之间没有建议

另外，为了不影响查询的性能，将大文件放入单独的表中通常是一个好主意 - 不要让巨大的斑点是您查询的常规表中的一部分 - 而是创建一个如果您确实需要文档或图像的兆字节，则只有单独的表格，您才曾经查询过。

因此，这可能会使您了解从哪里开始！

Answer 2

我强烈建议您考虑文件系统解决方案。原因是：

• 您可以更好地访问文件（如果进行调试时珍贵），这意味着您可以使用常规的基于控制台的工具
• 您可以快速轻松地利用OS来分配负载，例如使用分布式文件系统，通过硬件RAID添加冗余等。
• 您可以利用OS访问控制列表来执行权限。
• 您不堵塞数据库

如果您担心目录中的大量条目，可以始终创建一个分支模式。例如：

filename : hello.txt
filename md5: 2e54144ba487ae25d03a3caba233da71
final filesystem position: /path/2e/54/hello.txt

Answer 3

这个受欢迎的主题背后有很多“取决于”。由于您说这些文档是敏感和机密的，因此我可以在数据库中存储的袖口。以下几个原因：

• 潜在的更好的安全性。与数据库相比，黑客入侵文件系统通常更容易。
• 更好的音量控制。一个文件夹中的数千个文件可能会使一个操作系统限制，其中数据库可以在一个表中占用数百万行而不会闪烁。
• 更好的搜索和扫描。加载数据时添加分类列，或尝试全文索引扫描实际文档。
• 备份可能会更有效 - 只需在备份计划中添加另一个数据库，就可以掩盖（当然，一旦您完成了空间详细信息）。这些备份文件是试图获取敏感文件的任何人的另一层混淆。
• SQL Server 2008具有可能在这里有帮助的数据压缩选项。那是，或者申请做到了？ （也许通过混淆更多安全）

SQL Server 2008还具有FileStream数据类型，在这里可能会有所帮助，但我对此不太熟悉，无法为您的情况提供建议。