【问题标题】:Disadvantage of choosing large MAX value for varchar or varbinary为 varchar 或 varbinary 选择大 MAX 值的缺点
【发布时间】:2010-10-03 06:25:58
【问题描述】:

在创建 varchar 或 varbinary 列时选择较大的 max 值有什么缺点?

我正在使用 MS SQL,但我认为这也与其他数据库相关。

谢谢

【问题讨论】:

    标签: sql sql-server types varchar


    【解决方案1】:

    如果大量数据以某种方式进入(例如从外部接口),而您的应用程序不是为处理这些数据而设计的,那么您可能会增加破坏应用程序的风险。

    作为一个好的设计,您应该始终将字段的大小限制为一个实际值。

    【讨论】:

      【解决方案2】:

      这取决于在特定列中存储大量数据是否合理。

      如果您声明一个永远不会正确存储大量数据的列(即,员工的名字作为 VARCHAR(1000)),您最终会遇到各种问题

      1. 许多(如果不是大多数)客户端 API(即 ODBC 驱动程序、JDBC 驱动程序等)在客户端上分配足够大的内存缓冲区以存储特定列的最大大小。因此,即使数据库只需要存储实际数据,您也可能会大大增加客户端应用程序使用的内存量。
      2. 您无法从表定义中驱动数据验证规则(或传递有关数据的信息)。如果数据库允许 1000 个字符的名字,那么与数据库交互的每个应用程序最终都可能有自己的规则来决定员工姓名的大小。如果没有通过在所有应用程序和表之间放置存储过程层来缓解这种情况,这通常会导致各种应用程序具有各种规则。
      3. 墨菲定律指出,如果您允许 1000 个字符,那么最终会有人在列中存储 1000 个字符,或者至少是一个大到足以在一个或多个应用程序中导致错误的值(即没有人检查每个应用程序的员工姓名是否字段可以显示 1000 个字符)。

      【讨论】:

        【解决方案3】:

        取决于 RDBMS。 IIRC,MySql 为 varchars > 255 个字符分配 2 字节开销(以跟踪 varchar 长度)。 MSSQL

        [1] varchar(max) 有点特殊,但如果字段长度 > 8000 或行 > 8060,也会分配溢出页面。这是 MSSQL 默认设置,行为可以随数据行选项中的大类型。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2013-01-10
          • 2022-01-06
          • 1970-01-01
          • 2011-01-29
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多