【问题标题】:Storing many bits -- Should I use multiple columns or a single bitfield column?存储许多位——我应该使用多个列还是单个位域列?
【发布时间】:2010-07-30 17:39:39
【问题描述】:

我正在我的数据库中设计一个User 表。对于每个用户,我有大约 30 个选项,可以是“允许”或“禁止”。

我的问题是我应该将这些存储为 30 个 bit 列,还是应该使用单个 int 列来存储它们并解析应用程序中的每个位?

另外,我们的数据库是 SQL Server 2008 和 2005(取决于环境)

【问题讨论】:

    标签: sql sql-server-2005 sql-server-2008 database-design bit-fields


    【解决方案1】:

    我刚刚尝试创建两个表,一个具有单个 int 列,另一个具有 30 位列,然后为每个表添加一行,并使用 SQL Server Internals Viewer 来查看它们

    CREATE TABLE T_INT(X INT DEFAULT 1073741823);
    
    CREATE TABLE T_BIT(
    X1  BIT DEFAULT 1,
    /*Other columns omitted for brevity*/
    X30 BIT DEFAULT 1
    );
    
    INSERT INTO T_INT DEFAULT VALUES;
    
    INSERT INTO T_BIT DEFAULT VALUES;
    

    30 位列的表的单行

    表的单行一 int 列

    从存储的角度来看,SQL Server 结合了位列,并且数据存储在完全相同的空间量(黄色)中。你最终会为 NULL 位图(紫色)丢失一行 3 个字节,尽管它的长度与列数成正比(无论它们是否允许空值)

    字段键(int 版本,bit 版本颜色编码相同)

    【讨论】:

      【解决方案2】:

      两者都没有——除非您有重大的空间问题或与其他系统的兼容性要求,否则请考虑一下这将如何阻止您优化查询并清楚地理解每个位代表的含义。

      一个表中可以有超过一千列,也可以有一个用于用户设置的子表。为什么将自己限制在需要在应用程序中解析的 30 位?想象一下,如果其中一些设置被弃用或引入了一些新设置,您需要对应用程序进行哪些更改。

      【讨论】:

        【解决方案3】:

        我认为,如果每个值都有列,则允许将来进行扩展会更容易。如果您将来添加另一个选项(对于大多数类似的应用程序来说可能),那么它可能会影响您的所有其他代码,因为您需要重新解析您的 int 列以考虑新位。

        【讨论】:

          【解决方案4】:

          如果您组合成一个位标志字段,如果您正在查看原始数据,将很难看到设置的内容。我会为每个值使用单独的列,或者将选项存储在他们自己的表中。

          【讨论】:

            【解决方案5】:

            我同意您的设计应该正确规范化,三个表用户和用户设置,以及一个桥接表:

            用户:

            用户名 int

            用户名 varchar(X)

            用户设置

            设置id int

            设置名称 varchar(X)

            用户用户设置:

            用户名 int

            SettingId int

            IsSet 位

            桥表UserUserSettingUserSetting和User表之间会有FK,并且UserUserSetting中的t UserId,SettingId的唯一控制约束>

            【讨论】:

            • +1 Bravo 进行标准化。但是,是否需要 UserUserSetting。不应该存在一行表示为用户启用了用户设置吗?
            • 将每个用户设置视为属性而不是实体不一定违反 1NF。然而,问题的措辞方式确实将“用户设置”视为一个通用概念;在这个模型中,用户设置是一个实体,需要一个表。需要更多关于如何使用用户设置和具体示例的信息来了解哪种方法更适合。
            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2023-02-02
            • 1970-01-01
            • 2015-03-28
            • 1970-01-01
            • 2018-10-31
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多