问题标签 [filetable]

我想将图像存储在 sql 数据库中。图像的大小在 50kb 到 1mb 之间。我正在阅读有关 FileStream 和 FileTable 的信息，但我不知道该选择哪个。每行将有 2 个图像和一些其他字段。

图像永远不会被更新/删除，每天将插入大约 3000 行。

在这种情况下推荐哪个？

我在 Windows Server 2012 上使用 ASP.NET 创建一个 Web 应用程序。我使用的是 SQL Server 2014，我有一个 FileTable，文件表映射到以下路径\\CIHOST1\MSSQLSERVER\FileStreamDirectory\AvatarsFT\ SQL Server 和 IIS 都在同一台物理机器上。

当我将网站的应用程序池身份设置为以管理员身份登录时，应用程序可以读取和写入文件到路径，但是当我更改为默认应用程序池身份时，我得到拒绝访问异常，因此应用程序无法从中创建或读取文件UNC 路径。问题是要设置什么权限以及在何处使 ApplicationPoolIdentity 可以访问 SQL Server 文件共享。我的 ApplicationPoolIdentity 用户应该属于哪个组？

是否可以从 SQL Server 2014 中的文件表中检索实际文本？

我想实现一些高亮显示功能，但为了做到这一点，我需要检索我索引的文件中的实际文本，因为内容位于 varbinary 列中。

如果不可能，我想这样做的唯一选择是忘记 FileTables 并实现应用程序端的“文档阅读器”，这样我的“file_stream”列中就会有真实的文本，而不是 varbinary。或者甚至可以在一些 C# 代码后面定义一个使用 iFilters 的 UDF，对吧？

拜托，任何建议都会非常有用。

我目前处于文档管理系统开发的分析阶段，这将是来自许多应用程序的文档的唯一入口点。文件的大小和数量取决于应用程序。例如，其中一个将在一年内拥有 500,000 个文档，其中 468,000 个文档的大小小于 256 KB。乍一看，来自其他应用程序的文档大小可能是异构的

我提出的解决方案是创建一个 WCF Web 服务，充当外部应用程序和 SQL Server 之间的中间件，以便：

• 当 INSERT 文档
  • 外部应用程序会将应用程序 GUID 和文档作为字节 [] 发送到 WCF
  • WCF 会将文档插入数据库，并将唯一的 GUID 返回给 WCF，WCF 又会将其传递给外部应用程序以存储在自己的数据库中。
• 当 SELECT 文件
  • 外部应用程序会将文档 GUID 和应用程序 GUID 发送到 WCF，Web 服务会查询数据库并返回包含文件内容的字节流

高层架构如下（通过实体框架 6 访问数据）：

在考虑了各种替代方案后，我们选择使用 Filestream（截至 2008 年）和 FileTable（截至 2012 年）的功能。

从这个解决方案的数据库架构的角度来看，我对此表示怀疑，并且我担心数百万个文档存储在 FileTable 中时的未来性能（这也是我客户的主要关注点）。我不知道这种类型的功能（Filestream 和 FileTable）是否会影响小文件的性能。根据我在 Microsoft、MVP 等的不同博客中所读到的内容，他们建议对于小文件（小于 256 KB）在表中更好地存储为 VARBINARY(MAX)，如果文件为 1MB 或更大，则使用 Filestream。

我从未使用过 Filetable 和 Filestream，所以我不知道这种方法的性能。一年之内，多达 6 个不同的应用程序将在此存储库中转储文档，预计一年内将增长约 500 万个文档，这些文档的文件大小是异构的，而且乍一看无法确定。

对于实施，我提出了以下建议：

1. WCF 中的逻辑是，根据大小，文档存储在 VARBINARY 或表 FileTable 类型中。我会创建 2 个文件组（一个用于文件 <= 1MB，另一个用于 > 1MB）
2. 拥有与应用程序一样多的文件表和同样多的文件组。在有六个外部应用程序的情况下，我将有 6 个 FileTable，每个都有自己的 FILEGROUP，但在这种情况下，我不会区分每个文件大小，而是应用程序。

在上述之后，我需要有关此解决方案架构的建议以及有关硬盘、RAM、处理器等特性的建议。

背景

我正在研究创建一个简单的网络应用程序，其中一部分将显示与Items关联的图像。我决定研究使用SQL Server 的功能，该功能将允许将二进制图像数据直接上传到公开的共享中。因此，有一个用例允许通过 Windows 资源管理器删除文件（a 中的行）。此示例复制了该问题，该问题源于与.FILETABLEFILETABLEFILETABLE

结构

已经使用文件资源管理器将图像添加FILETABLE到:path_locator0xFF5354649088A1EFEE8F747CD11030F80800170620

问题

通过文件资源管理器删除文件后...

...文件从目录中消失，因为 Windows 报告删除成功，但该行没有从FILETABLE.

但是，当尝试通过 SQL Server 删除时，抛出熟悉的引用约束冲突错误：

我向 中添加了一个AFTER DELETE触发器，FILETABLE目的是删除引用行，但这也没有被执行。

问题

• 在通过 Windows 资源管理器删除时，如何通过链接表传播删除？
• 是否有某种 SQL Server/Windows API 挂钩可以检测并执行处理删除的 DML 代码？

更新#1

从BOL开始，以下部分确认了该行为，尽管没有提供任何进一步的信息。

事务语义

当您使用文件 I/O API 访问 FileTable 中的文件时，这些操作与任何用户事务无关，并且具有以下附加特征：

• 由于对 FileTable 中 FILESTREAM 数据的非事务访问与任何事务无关，因此它没有任何特定的隔离语义。但是，SQL Server 可以使用内部事务对 FileTable 数据强制执行锁定或并发语义。这种类型的任何内部事务都是通过读提交隔离完成的。

这基本上是一个是/否的问题，但如果答案包括支持参考和操作方法，如果答案是“是”，我们将不胜感激。奇怪的是，我在 MSDN 或 TechNet 中找不到明确的答案，而我的直觉和实验使我得出了“否”的结论。

是否可以将 Windows EFS 与 SQL Server 2012 的 FILESTREAMS 和 FileTables 一起使用，并对这些 FILESTREAMS 进行全文搜索？

TIA

附加细节

我创建了一个 Visual Studio SQL 项目，该项目使用 FileTables 上的 FILESTREAMS 标记数据库，并且全文搜索正常工作，所以我知道基线很好。从那里我尝试了两件事。

1. 浏览到物理FileTable 文件夹并使用 EFS 对其进行加密。这可能是错误的方法，因为我在创建数据库、日志和文件流之后添加了加密。SQL 错误是“Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when received results from server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the server.)管道。）”禁用物理文件夹上的加密会使事情变得正确。

2. 首先加密物理目标文件夹，然后部署 SQL 项目（因此 .MDF 和 .LDF 也在磁盘上加密）。这似乎效果更好，但是当我浏览 UNC 路径 (\MyMachine\MSSQLSERVER\NewDb\Files) 并将文件复制到那里时，我从 Windows 收到错误：“目标文件夹访问被拒绝。您需要权限才能执行此操作。 " 所以搜索可能有效，但我无法将文件放入文件夹中。

我已经让 SQL Server 2012 与我的 Visual Studio SQL 项目一起工作，正如我在其他 SO 帖子中更详细地讨论的那样。启用 FILESTREAMS，在它们自己的 FileGroup 中创建 FileTables，并且我的 SQL 项目生成良好的可索引/可搜索 FILESTREAM DB，只要禁用 EFS（加密文件系统）。当我在物理路径上启用 EFS（在 SQL 的数据目录上启用）时，我无法读取或写入文件到 FileTable Win32 共享。FWIW，我可以通过共享创建和删除目录。

从我在Bruce Jackson 的博客上读到的内容来看，它应该“正常工作”，但现在，启用或禁用 EFS 就像一个切换：EFS on => 拖放到/从共享获得权限被拒绝；EFS 关闭=> 拖放到共享中/从共享中拖放效果很好。

SQL Server 在其自己的本地帐户下运行，并且我正在作为我的域帐户执行所有其他操作（使用 SSMS、Windows 资源管理器等），该帐户是本地管理员并映射到 SQL Server 中的 dbo。我想我应该有足够的权限。此外，通过 SSMS 查询 BLOBS 也可以正常工作。启用 EFS 时，它只是破坏了 Win32/UNC 共享访问。

有谁知道可能出了什么问题？

我的FileTableSQL Server 2012 数据库中有一个，其中包含文件夹和文件。我想重命名一个文件夹，所以我执行了

update MyFileTable set name = 'NewName' where name = 'OldName';

更新成功，当我从中选择时，文件表反映了新名称。但是，当我进入 Windows 资源管理器并导航到相应的文件夹位置时，不会反映新名称。我尝试刷新并稍等片刻，然后刷新，但该文件夹仍然具有旧名称。当我尝试打开文件夹（使用旧名称）时，它会给出一个错误，指出该位置无效（或类似的东西），并且在单击“确定”后，该文件夹消失了。

但是，如果我尝试使用新名称在同一位置创建一个新文件夹，则会收到该文件夹​​已存在的错误消息。当我单击“确定”时，出现了新名称的文件夹，加上一个名称为“新文件夹”的新文件夹（由于尝试创建名称为 的文件夹不成功NewName。删除文件夹后New folder，我得到了想要的结果：文件表已更新，新名称反映在 Windows 资源管理器中。

因此，似乎文件表大部分都在工作，但是我如何确保在查询或存储过程中执行的名称更改（或其他更改）将反映在文件共享中？

我用谷歌搜索，但没有找到任何讨论这个问题的东西。

编辑：
在将新记录插入文件表时，我注意到了类似的事情。新记录（本例中为文件夹）在创建后不会显示在 Windows 资源管理器中，即使它们确实出现在文件表中。然而奇怪的是，在尝试了不同的事情之后，Windows 资源管理器中同时出现了五个最近创建的文件夹。所以，也许只是有一个滞后。有没有人有类似的经历？

我FileTable首先在我的项目中使用 SQL Server 2014 和 EF 代码。

当我使用这个命令

它在 sql 中显示此警告

当 FILESTREAM 数据库选项 NON_TRANSACTED_ACCESS 设置为 FULL 并且 READ_COMMITTED_SNAPSHOT 或 ALLOW_SNAPSHOT_ISOLATION 选项打开时，将阻止对 FILETABLE 上下文中的 FILESTREAM 数据的 T-SQL 和事务性读取访问。

现在我继续创建表，插入文件夹和文件没有问题。

我读取数据的问题，当读取数据时显示此错误：

消息 33447，级别 16，状态 1，行 2
无法访问 FileTable 'File' 中的 file_stream 列，因为 FileTable 不支持行版本控制。将事务级别设置为 READ COMMITTED SNAPSHOT 或 SNAPSHOT 以外的其他值，或者使用 READCOMMITTEDLOCK 表提示。

我首先使用 EF 代码 - 如何解决这个问题？

我正在开发一个使用 Filestream / FileTable 作为文档存储的自定义文档管理系统。

目录结构如下：APPNameDir --> Year --> Month --> Files

+ APPNameDir + 2015 + 12 File 1.pdf File 2.pdf + 2016 + 01 File 3.pdf File 4.pdf + 02 File 5.pdf File 6.pdf

我想要做的是从 C# 代码调用存储过程并传递文件夹树（例如（BooksApp/2016/03）和 file_stream 数据。

然后，在存储过程中我想检查文件夹树是否已经存在，否则创建不存在的文件夹。

我看过这篇文章，所以我可以一次创建一个文件夹，但不能一次创建多个文件夹。

我想我可以检查 2016 是否不存在，然后创建它。然后，检查第 03 个月是否不存在，然后创建它等等，但我担心数据库中有数百万个文档时的性能，因为我想在不到 2 秒的时间内从 Web 应用程序插入文档（这是一个限制）。几天前我做了一些性能基准测试，当数据库中有 100K 文档时，从 Web 应用程序插入文档需要 100 到 300 毫秒。如果我必须查询每个目录的 FileTable，然后在它们不存在时创建它们，我担心当数据库中的文档数量如此之多时性能会降低。

您是否在项目中遇到过类似的需求？任何想法？