SqlServer和nvarchar(最大)

时间:2011-02-02 15:13:54

标签: sql sql-server sql-server-2005 sql-server-2008

我们目前正在考虑将字符串列设置为nvarchar(max),而不是指定特定长度以防止在数据库中没有足够空间存储字符串的任何问题。我只是想知道这是不是一件好事,或者它是否会引起任何问题,因为可以这样做,为什么要指定nvarchar(10)而不是nvarchar(max)这样的长度。我们也经常使用varbinary(max),因为我们不知道我们需要多少二进制数据所以我不确定这是多少效果要么我们的插入没有我想的那么快。这是一个示例表:

CREATE TABLE [dbo].[SAMPLETABLE] (  
[ID] [uniqueidentifier] NOT NULL,  
[FIELD1] [int] NOT NULL,  
[FIELD2] [nvarchar] (2000) NULL,  
[FIELD3] [nvarchar] (max) NULL,  
[FIELD4] [uniqueidentifier] NULL,  
[FIELD5] [int] NULL,  
[FIELD6] [nvarchar] (2000) NULL,  
[FIELD7] [varbinary] (max) NULL,  
[FIELD8] [varbinary] (max) NULL,  
[FIELD9] [varbinary] (max) NULL,  
[FIELD10] [uniqueidentifier] NULL,  
[FIELD11] [nvarchar] (2000) NULL,  
[FIELD12] [varbinary] (max) NULL,  
[FIELD13] [varbinary] (max) NULL,  
[FIELD14] [bit] NULL,  
[FIELD15] [uniqueidentifier] NULL,  
[FIELD16] [varbinary] (max) NULL,  
[FIELD17] [bit] NULL,  
[FIELD18] [tinyint] NULL,  
[FIELD19] [datetime] NULL,  
[FIELD20] [nvarchar] (2000) NULL,  
PRIMARY KEY CLUSTERED   
(  
    [ID] ASC  
)
) ON [PRIMARY]  

GO

考虑到这样的表设计并将nvarchar(2000)更改为nvarchar(max)会使事情变得更糟(或更好)? sqlserver不喜欢这样的设计吗?

6 个答案:

答案 0 :(得分:11)

如果你对J. Random Developer感到满意,6个月后,将莎士比亚的作品插入每一栏,那就好了。

对我来说,数据建模的很大一部分是认真思考我希望在每列中允许哪些数据,以及我希望禁止哪些数据。然后,我应用适当的CHECK约束来实现这些限制(最好的SQL Server允许)。 “免费”进行合理的长度检查似乎总是一种奖励。


你也没有做太多的“未来验证” - 我相信,在以后将(n)varchar列的长度更改为更大的值,纯粹是元数据操作。所以我会说适当的列大小适合你今天要处理的数据(好的,明年左右)。如果您以后需要扩展它们,则需要几秒钟的时间。

答案 1 :(得分:5)

我们希望您不要使用该列进行搜索或使用唯一值...

索引不能超过900字节宽所以你可能永远不会创建索引。这是一个缺点:因为它给出了

  • 搜索性能非常糟糕
  • 没有唯一约束

它可以解决计算列,但为什么不存储你需要的

答案 2 :(得分:4)

从行内类型切换到BLOB类型始终是一个重大决定。您必须内化BLOB类型(VARCHAR(MAX)NVARCHAR(MAX)VARBINARY(MAX))在内部与行内类型完全不同的类型:

因此,将所有列切换为BLOB类型可能会带来许多您未考虑的副作用:无法索引BLOB列,缺少在线操作,由于BLOB固有的较慢代码等导致的一般性能下降等最严重障碍可能是您在制作BLOB后无法索引列的事实。如果这不是一个显示阻止,那么你将不得不测试和衡量性能影响。

其他人提出的数据建模问题一般都是有效的,但据我所知,在现实世界中,这个理论只能在理论上起作用......

答案 3 :(得分:3)

答案与“当我可以将所有数字存储为字符串时为什么需要指定int?”的答案相同。 - 因为它有助于:

  • 速度效率。
  • 存储效率。
  • 作者/建筑师的意图。
  • 减少了数据错误,因为只有某种数据适合。

但它不会立即引起任何明显的“问题”,因为nvarchar(10)是nvarchar(max)的子集。

答案 4 :(得分:0)

这是我给另一个想要无尽桌子的人的答案:

Database alternative to MySQL made for millions of TABLES

对于任何关系数据存储,上述位置都不是最佳设计。 Pop为数据添加黄鼠狼:只需选择一个你可能得到你想要的数据。

也许没有sql解决方案可以更好地工作,因此您可以拥有动态数据而不用担心列限制。

我认为如果我们要回答问题,那么我也认为,当有不良设计的替代品时,我们应该提供最佳/更好的做法。

想想那个跟你一样的人,就像KM上面说的那样

答案 5 :(得分:0)

根据我的经验,不过很多2000个字符长的字段最终被编入索引。我认为使用nvarchar(max)比使用一些仲裁长度要好得多,如果数据不够长,你可能需要截断数据。

我看到的一个例子是一个错误日志表,其中表设计者尚未准备好将调用堆栈存储在nvarchar(max)字段中,因此它们存储了前n个字符,导致截断的调用堆栈缺少最有趣的部分。