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