我需要的二进制文件存储在SQL Server 2005这样一个VARBINARY(max)列:
的FileInfo
- FileInfoId INT,PK,身份
- FILETEXT VARCHAR(最大)(可以为null)
- FileCreatedDate日期时间等。
FileContent
- FileInfoId INT,PK,FK
- FileContent VARBINARY(最大值)
FileInfo的有一个与FileContent一个关系。 该FILETEXT是指在没有文件上传,只有文本将被手动输入一个项目中使用。 我不知道有多少比例的项目将有一个二进制文件。
我应该创建第二个表。 会不会有任何的性能改进与两个表的设计? 是否有任何合乎逻辑的好处是什么?
我发现这个网页 ,但它是否适用于我的情况不知道。
没有性能上也不是运营优势。 由于SQL 2005的LOB类型已经存储了您引擎在一个单独的分配单元,独立的B树。 如果你研究的表和索引组织的SQL Server,你会看到,每个分区有多达3个分配单元:数据,LOB以及行溢出:
一个LOB字段(varchar(max),为nvarchar(最大),VARBINARY(最大值),XML,CLR的UDT以及过时的类型的文本,ntext和image)将在数据记录本身,聚集索引,只有一个非常小的足迹:一个指针到LOB分配单元,看到一个记录的剖析 。
通过在一个单独的表显式存储LOB 你获得绝对没有 。 你只需要添加不必要的复杂性为前原子更新现在已经分配自己变成两个独立的表,应用程序和应用程序交易结构复杂化。
如果LOB内容是一个完整的文件,那么也许你应该考虑升级到SQL 2008和使用FILESTREAM 。
有没有真正的合乎逻辑的优势,这两个表的设计,因为关系是1-1,你可能在FileInfo的表捆绑在一起的所有信息。 不过,也有严重的操作和性能优势,特别是如果你的二进制数据超过几百个字节大小,平均。
编辑 :由于通过瑞摩斯Rusanu指出,在某些DBMS实现如SQL2005,大的对象类型被透明存储到一个单独的表,有效缓解具有大的记录的实际缺点。 引入此功能的含蓄确认了[真]单表方法的弱点。
我只是扫描在这个问题上的SO发帖引用。 我一般件事,而其他张贴使得一些正确的观点,如内部数据完整性(因为在给定项目的所有CRUD操作是原子),但就整体而言,除非比较典型使用案例(如使用项目表作为主要一次查询了单品的仓库),性能优势与两个表的方法(其中的“头”表的索引会更有效率,不需要二进制数据将返回更快地等查询。等)
而且,这两个表方法在情况下,设计过程中在不同的充情况下提供不同类型的二进制对象的更多的好处。 例如,假设这些物品的图像(GIF格式,JPG格式等)。 在以后的日子你也想提供这些图像(和/或高分辨率版本),在此选择由上下文驱动(用户偏好,低频段宽客户端,用户对游客的小型预览版等等。)。 在这种情况下,不仅是与单个表方法相关的操作问题变得更加尖锐,模型变得更通用。
它可以帮助独立的图像,(N)TEXT,(N)VARCHAR(MAX)和VARBINARY(最大值)的列宽出表的纯粹的SQL Server的一些限制。
例如在2012年之前不可能在网上重建簇表,如果它包含的LOB。 在另一方面,你可能不会在意这些限制,因此,在设置表像你的数据是相关的是更好的事情。
如果你身体要保持LOB数据出来,你仍然可以设置“大值类型在行外”表分配单元的表选项 。