我们的一个团队正在构建一个数据库（和应用程序），它将使用SQL 2008的FileStream功能来存储文档。根据MS的文件流最佳实践，与使用T-SQL相比，Win32 API是访问FileStream数据的首选方式。
但是，使用Win32 API需要使用集成身份验证才能连接到数据库。这是团队关心的问题，因为他们不想让用户直接访问数据库。他们希望应用程序使用SQL用户名和密码进行连接。
使用Win32 vs T-SQL访问文件流数据的优缺点是什么？是否有任何因素会导致无法使用T-SQL？
答案 0 :(得分：5)
T-SQL和Win32 Filestream访问之间的主要区别在于数据传输到客户端的方式 - 使用T-SQL检索文件流数据意味着存储引擎必须在NTFS上打开文件，通过SQL引擎传输数据并通过TDS（SQL数据传输的标准方式）返回客户端。如果使用Win32，存储引擎在打开文件操作期间仍然在路径中，但是一旦完成，数据就可以通过Win32流直接从文件传输到客户端，完全绕过SQL引擎。
随着blob大小增加，打开文件和通过引擎传输的开销变为完成数据传输所需总时间的较小百分比。最近针对特定案例研究的基准测试，内联（varbinary max storage）的阈值为60KB，T-SQL传输的阈值为60KB-1.2MB，Win32传输的阈值为1.2MB。正如我所提到的，这是一个非常具体的案例，所以YMMV。
就安全性而言，我可以看到以这种方式使用SQL安全性的许多问题，但是如果没有更多的上下文，很难提供建议。通过仅通过T-SQL访问它，您实际上无法从文件流中获益。
答案 1 :(得分：3)
首先让我们分析一下问题：嵌入式用户名和密码比使用Windows身份验证更安全。这是一个令人尴尬的错误假设。所有这一切都给人一种虚假的安全感。作为 fact 的问题，人们无法在应用程序中隐藏秘密。它可以始终显示出来。在这个时代，只需要一个勇敢的黑客来揭示嵌入式密码，或者如何检索它的方法，感谢谷歌和朋友们，每个感兴趣的人都会学习它，无论如何他或她不熟练。在安全性分析中，用户工作站上的“隐藏”登录名和密码应被视为安全，就好像它们是以书面形式交给所述用户一样。通过使用隐藏的登录名和密码作为保护访问的手段，您实现的就是松散的问责制以及谁所做的跟踪记录，当他们这样做时。始终依靠适当的访问权限来实现安全保护。永远不要依赖于在攻击者的机器上“隐藏”的混淆密码。
如果你想要一个允许用户只能访问特定功能的保护方案（即他们只能以这种方式更新数据而不是写任意UPDATE），请使用good ole'试过通过存储过程测试ownership chains的方法，并仅授予对 true 身份验证用户的EXECUTE访问权限。要获得更好的解决方案，请使用code signing。
对于T-SQL与Win32访问，FILESTREAM Best Practices文档包含以下措辞：
- FILESTREAM API专为。而设计 Win32流式访问数据。避免 使用Transact-SQL进行读写 FILESTREAM二进制大对象 （BLOB）大于2 MB。如果 您必须从中读取或写入BLOB数据 Transact-SQL，确保所有BLOB 在尝试之前会消耗数据 从Win32打开FILESTREAM BLOB。 没有消耗所有的 Transact-SQL数据可能会导致任何问题 连续的FILESTREAM打开或关闭 操作失败。
- 避免使用Transact-SQL语句 更新，附加或预先添加数据 FILESTREAM BLOB。这导致BLOB 要假脱机到tempdb的数据 数据库然后又回到新的 物理文件。