SqlServer和nvarchar（最大）

我们目前正在考虑将字符串列设置为nvarchar(max)，而不是指定特定的长度以防止数据库中没有足够空间存储字符串的问题。林只是想知道这是一件好事，或者它可以导致任何问题，因为它可以做，那么为什么指定一个长度，如nvarchar(10)，而不是nvarchar(max)。我们也使用varbinary(max)很多，因为我们不知道我们需要多少二进制数据，所以我不知道这是一个效果多少，或者让我们的插入速度没有我认为应该的那么快。这是一个示例表：SqlServer和nvarchar（最大）

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是否对这样的设计皱眉头？

来源

2011-02-02 user455095

你存储什么样的数据？唯一的*问题*将是索引，搜索和约束。尽管如此，这并不是一个好主意。 – Matthew 2011-02-02 17:57:16

**请不要这样做！**如果我在一个拥有这样的桌子的地方被雇用，我会跑出大门！然后，在所有nvarchar（max）列yuck顶部添加聚簇uniqueidentifier PK。你正在杀死你索引数据的能力。不久的将来，你会回过头来问一个关于你的查询运行速度如此缓慢的问题，并且不会有太多的事情可以加快速度。当天，所有主流/流行语言都是强类型的，但现在还没有那么多。如果你尝试在数据库中使用“那个”拐杖，你会遇到问题。 – 2011-02-02 19:40:21

@KM如果可以的话，我会百万次提出你的评论，这是可怕的数据库设计。 – HLGEM 2011-02-02 20:24:09

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

对我来说，数据建模的一个重要部分是认真考虑我想在每列中允许的数据以及我希望禁止的数据。然后我应用适当的约束来实现这些限制（如同最好的SQL Server允许的那样）。有一个明智的长度检查可用“免费”总是看起来像一个奖金。

你也没有做太多的“未来验证” - 在日后改变（n）的VARCHAR列到一个较大的值的长度，我相信，一个纯粹的元数据操作。所以我会说适当的大小列的数据，你今天要处理的数据（和好的，未来一年左右）。如果您需要稍后扩展它，则需要几秒钟的时间。

来源

2011-02-02 15:19:03

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

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

但是它不会立即引起任何明显的“问题”，因为nvarchar（10）是nvarchar（max）的一个子集。

来源

2011-02-02 15:20:17 iain

我们希望您不要使用列搜索或具有唯一值...

索引不能超过宽900字节，因此，你可能永远无法创建索引。这是一个缺点：因为它给

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

它可以围绕与计算列来工作，但为什么不储存你需要？

来源

2011-02-02 17:50:41 gbn

从行内类型切换到BLOB类型始终是一个重大决定。你必须内化的BLOB类型（VARCHAR(MAX)，NVARCHAR(MAX)和VARBINARY(MAX)）是完全不同的，从行内类型内部类型：

他们去到不同的分配单元，看到Table and Index Organization
它们不能是索引
的到不同的存储选项视在sp_tableoption
他们使用完全不同的处理的代码路径，看到Performance comparison of varchar(max) vs. varchar(N)
在线运在带有BLOB的表上不允许使用表（请参阅ALTER INDEX ... REBUILD ... WITH (ONLINE= ON)处的例外情况。估计是因为你的表已经有BLOB的，这不会是一个问题

所以切换所有列BLOB类型有很多副作用，可能会带给你有没有考虑过：不可能建立索引的BLOB列，缺乏的在线操作，由于BLOB固有的较慢代码等导致的普遍性能下降等等。最严重的障碍可能是这样的事实，即在使它们成为BLOB之后，您将无法对列进行索引。如果这不是一个限制，那么你将不得不测试和测量性能影响。

的数据建模的担忧等纷纷上调是总体有效，但据我所知，往往在现实世界的理论只能在理论上...

来源

2011-02-02 18:51:54

下面是我给另一个男人谁想要同样的答案无端表：

Database alternative to MySQL made for millions of TABLES

即上述位是小于优化设计任何关系的数据存储。 Pop进入数据库的黄鼠狼：选择一个你可能会得到你想要的数据。

也许一个没有sql的解决方案会更好，所以你可以拥有动态数据而不用担心列限制。

我认为，如果我们要回答问题，那么我认为我们应该提供最佳/更好的做法，当有坏的设计交替出现时。

想以后你来的家伙作为KM以上

来源

2014-08-14 22:37:03 Tab

说，以我的经验并不多2000个字符长的领域最终虽然索引。我认为使用nvarchar（max）比一些任意长度更好，如果数据不够长，您可能必须截断数据。

我看到的一个例子是一个错误日志表，其中表设计者没有准备将调用堆栈存储在nvarchar（max）字段中，所以他们存储了前n个字符，导致截断的调用堆栈最有趣的部分缺失。

来源

2016-06-07 13:44:45 Cato

SqlServer和nvarchar（最大）

回答

相关问题