我想知道将 NVARCHAR 字段设置为 MAX 而不是 SQL Server 2008 中的特定大小会产生什么后果，并限制应用程序逻辑的输入。另外，这些会是一个糟糕的设计实践吗？
问问题
7197 次
6 回答
7
NVARCHAR(MAX) 在处理较小数据方面比旧的 NTEXT 数据类型要好得多，但是，NVARCHAR(n) 在某些领域总是更有效。
作为一般规则，使用最能代表您存储的数据的数据类型几乎总是最佳实践。
于 2009-05-28T11:27:04.177 回答
5
有很多性能影响。特别是，在通用字符串填充标量 UDF 中，我注意到在将输出声明为 VARCHAR(MAX) 时存在巨大的性能差异，即使输入从未超过 40 个字符。更改为 VARCHAR(50) 取得了巨大的进步。
于 2009-05-28T11:21:52.300 回答
3
如果您知道由于 SQL 存储此类数据的方式，它们永远不会包含超过有限数量的字符，则不应将所有字段设置为 NVARCHAR(MAX) - 足够小以适合页面的数据将存储在页面，但是当它变得太大时，它将被移出页面并单独存储。
另外，您确定需要 NVARCHAR，因为它存储占用两倍于标准 VARCHAR 空间的 unicode 数据？如果您知道您将使用标准字符，请改用 VARCHAR。
慢慢地，想想你的应用程序的用途。如果您的地址字段在理论上没有大小限制，您将如何将其打印在信封上？你说你会在前端应用中实现逻辑，但是为什么还要让数据库有太大的数据呢？如果数据进入破坏了前端逻辑的数据库会发生什么？
于 2009-05-28T11:18:28.157 回答
3
只是为了补充所有其他答案：还要注意数据可能来自其他来源的情况，例如 - 仅作为示例 - 从应用程序外部导入的文本文件；这可以绕过任何应用程序逻辑，除非您在导入例程中复制它......
于 2009-05-28T12:30:11.257 回答
1
主要缺点是NVARCHAR(MAX)无法使用普通索引进行索引。
NVARCHAR(MAX)此外，类型变量和解析这些变量的函数的性能也存在一些问题。
如果您只想按原样存储和检索数据，而不是在SQL Server' 端解析它，那NVARCHAR(MAX)很好。
于 2009-05-28T11:24:16.867 回答
0
设置限制对最大长度有一些验证的副作用
于 2009-05-28T11:36:46.810 回答