【问题标题】:What problems can an NVARCHAR(3000) causeNVARCHAR(3000) 会导致什么问题
【发布时间】:2008-11-20 15:33:15
【问题描述】:

我有一张已经很大的桌子,我的客户要求我延长备注字段的长度。 notes 字段已经是 NVARCHAR(1000),我被要求将其扩展为 3000。长期解决方案是将便笺移出表并创建一个使用仅连接的 NVARCHAR(max) 字段的便笺表在必要时。我的问题是关于短期的。知道这个字段将来会被移出,如果我现在只将该字段增加到 NVARCHAR(3000),我会遇到什么问题?

【问题讨论】:

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


    【解决方案1】:

    text 和 ntext 被弃用,取而代之的是 varchar(max) 和 nvarchar(max)。所以 nvarchar(3000) 应该没问题。

    【讨论】:

      【解决方案2】:

      您可能已经知道这一点,但请确保增加的长度不会使您的总记录长度超过 8000。我很确定这仍然适用于 2005/2008 年。

      【讨论】:

        【解决方案3】:

        对于临时解决方案,您应该可以使用 nvarchar(3000)。您最多可以使用 nvarchar(4000)。正如 km.srd.myopenid.com 之前发布的那样,确保行的整个长度不超过 8000(请记住,nvarchar 是常规 varchar 大小的 2 倍 - 这就是为什么您只能使用 nvarchar(4000 ),但您可以使用 varchar(8000))。

        【讨论】:

          【解决方案4】:

          我建议将列更改为 NTEXT。您对数据量几乎没有限制,并且数据不会与其余的行数据一起存储。这有助于防止您达到最大行大小限制。

          唯一的缺点是您只能在该列上执行“LIKE”搜索,并且无法为其编制索引。但是,如果它是一个注释字段,我猜你根本没有对其进行任何搜索。

          【讨论】:

            【解决方案5】:

            您可能还会遇到更慢的情况,因为您的数据页面可能会被拆分以容纳更大的字段。通过这样做,您可以创建一个允许超过 8060 字节的记录的结构,但请注意,如果您尝试添加实际包含的数据记录多于该数据记录,则会出现问题。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2020-11-18
              • 2015-12-30
              • 2021-03-12
              • 1970-01-01
              • 1970-01-01
              • 2012-01-05
              相关资源
              最近更新 更多