在不牺牲性能的情况下存储大型文本字段的可维护方法是什么？

我一直在围绕这个问题跳舞,但它一直在上升.我们有一个系统,我们的表格可以从最初存储为一个描述开始,NVARCHAR(150)然后我们得到一张票,要求将字段大小扩展到250,然后是1000等等......

在我们添加到大多数表的"note"字段和/或"description"字段上重复该循环.当然,我关注的是性能并打破了页面的8k限制.但是,我的另一个问题是通过将系统中的每个表中的这些字段分解为延迟加载的引用,使系统的可维护性降低.

所以在这里我面对的是同样的两个选项,一直盯着我.(欢迎其他人)请借给我你的意见.

更改所有可能的注释和/或说明,NVARCHAR(MAX)并确保我们在所有列表中排除这些字段.基本上永远不会做:SELECT * FROM [TableName]除非它只检索一条记录.

删除所有注释和/或描述字段,并使用对[Notes]表的forign键引用替换它们.

CREATE TABLE [dbo].[Notes] (
[NoteId] [int] NOT NULL,
[NoteText] [NVARCHAR](MAX)NOT NULL )

显然我更喜欢使用选项1,因为如果我们选择2,它会在我们的系统中发生很大变化.但是如果选项2真的是唯一的好方法,那么至少我可以说这些变化是必要的,我已经完成了家庭作业.

更新:我在一个包含100,000条记录的示例数据库上运行了多次测试.我发现由于集群索引扫描选项1所需的IO大约是选项2所需的两倍.如果我选​​择大量记录(1000或更多),即使我做了选项1也是两倍慢不包括选择中的大文本字段.随着我请求更少的行,线条模糊更多.我是一个网页应用程序,其中页面大小为50左右是常态,因此选项1将起作用,但我将在(非常)不久的将来将所有实例转换为选项2以实现可伸缩性.

选项2更好有几个原因:

查询表时,大文本字段会快速填满页面,迫使数据库扫描更多页面以检索数据.当您实际上不需要返回文本数据时,这尤其费力.

正如您所提到的,它为您提供了一个干净的休息时间来一次性更改数据类型.Microsoft已在SQL Server 2008中弃用了TEXT,因此您应该坚持使用VARCHAR/VARBINARY.

单独的文件组.将所有文本数据放在较慢,较便宜的存储位置可能是您决定在将来继续使用的内容.如果没有,没有伤害,没有犯规.

虽然选项1现在更容易,但选项2将为您提供更长期的灵活性.我的建议是实现一个简单的概念验证,其中"notes"信息与主表分开,并对两个示例执行一些查询.比较针对这些表的一些查询的执行计划,客户端统计信息和逻辑I/O读取(SET STATISTICS IO ON).

对于那些建议使用MSDN中的TEXT/NTEXT的人的快速说明:

将在Microsoft SQL Server的未来版本中删除此功能.避免在新的开发工作中使用此功能,并计划修改当前使用此功能的应用程序.请改用varchar(max),nvarchar(max)和varbinary(max)数据类型.有关更多信息,请参阅使用大值数据类型.