代码之家 › 专栏 › 技术社区 › DCNYAM

FileStream:T-SQL与Win32

filestream sql-server-2008 sql-server

DCNYAM · 技术社区 · 14 年前

但是,使用Win32 API需要使用集成身份验证来连接到数据库。这是团队关注的问题,因为他们不想让用户直接访问数据库。他们希望应用程序使用SQL用户名和密码进行连接。

使用Win32与T-SQL访问filestream数据的优缺点是什么?有没有什么因素会使使用T-SQL变得不可能?

2 回复 | 直到 14 年前

MikeW 14 年前

T-SQL和Win32 Filestream访问之间的关键区别在于数据传输到客户端的方式—使用T-SQL检索Filestream数据意味着存储引擎必须在NTFS上打开文件,通过SQL引擎和TDS(传输SQL数据的标准方式)将数据流回客户端。如果使用Win32,则在打开文件操作期间,存储引擎仍在路径中,但是一旦完成,数据可以通过Win32流直接从文件传输到客户端,完全绕过SQL引擎。

随着blob大小的增加,打开文件并通过引擎进行传输的开销在完成数据传输所需的总时间中所占的百分比会变小。最近针对一个非常具体的案例研究的基准测试将内联(varbinary max storage)的阈值设置为60KB,T-SQL传输的阈值设置为60KB-1.2MB,并且>1.2MB用于Win32传输。正如我提到的,这是一个非常具体的案件,所以YMMV。

Remus Rusanu 14 年前

首先让我们分析一下问题:嵌入的用户名和密码比使用Windows身份验证更安全。这是一个令人尴尬的错误假设。它所做的一切都给人一种虚假的安全感。作为一个问题事实 ,则不能在应用程序中隐藏秘密。它可以被揭露。在这个时代一勇敢娴熟的黑客透露嵌入的密码,或如何检索它的方法,并感谢谷歌和朋友所有感兴趣的人都会学习它,无论他或她是多么不熟练。在安全分析中,用户工作站上“隐藏”的登录名和密码应被视为安全的,就像它们是以书面形式交给所述用户一样。通过使用一个隐藏的登录名和密码作为手段,以保护访问所有你实现的是你松散的责任和跟踪记录谁

如果您希望保护方案只允许用户访问特定的功能(即,他们只能在这与编写任意更新不同的是,使用优秀的ole“久经考验的 ownership chains 并只授予对已验证的用户。要获得更好的解决方案,请使用 code signing .

FILESTREAM Best Practices 文件包含以下措辞:

FILESTREAM API是为使用Transact-SQL读写 FILESTREAM二进制大对象 (blob)大于2 MB。如果必须从中读取或写入BLOB数据 Transact-SQL,确保所有BLOB 从Win32打开FILESTREAM BLOB。 Transact-SQL数据可能导致

避免Transact-SQL语句将数据更新、追加或预先添加到文件流BLOB。这会导致斑点要假脱机到tempdb的数据然后回到一个新的数据库物理文件。