【问题标题】:Database Structures with a Large Number of Bit Fields具有大量位域的数据库结构
【发布时间】:2009-04-08 03:07:25
【问题描述】:

我有一类具有大量二进制属性的数据——准确地说是 151 (!)——我关心的是如何在结构上对这些数据进行建模。尽管将位域存储为字节的内部效率很高,但我的编程感觉却在创建具有 151 个位域(以及其他属性)的表时感到刺痛。

不会有大量的行——也许是 1000 行,并且一旦投入生产就不会经常改变。

我曾考虑将我的数据分类为不相交的子类并创建单独的表,但以这种方式拆分属性是不切实际的,即使可能也肯定不会有效地映射到数据子类。另一个问题是我想将所有数据放在一起并避免字段和/或行重复。我也考虑过使用一些自定义二进制格式,但这不可行,因为我的数据中的键字段被用作其他表中的外键。

查询将大量使用 WHERE 子句来提取相关数据。我考虑过使用多个 long 或 int 字段,但我认为这是不可行的,因为我不知道 SQL 中没有按位与运算符或函数,并且如上所述,属性的分类是有问题的,更不用说其他主要的软件工程问题(使用此方法)。

我将使用 PostgreSQL。

所以,我的问题是我只是制作一个包含大量字段的表格还是有其他与关系模型兼容的方法?

【问题讨论】:

    标签: database data-structures


    【解决方案1】:

    我看到的最大问题是,单字段索引的基数至少可以说很低。也许您可以多描述一下数据,我们可以讨论其他设计?例如,所有这些都是相互独立的吗?

    只有 1000 行,将其存储在其他地方可能比数据库更简单(尽管我想有很多连接机会?)不是出于查询效率的原因,但它看起来并不像数据库数据。

    【讨论】:

    • +1。同意数据库可能不是此数据的最佳位置。使用适当的掩码进行逐位测试似乎更合适。
    • 这实际上是我最初的计划,但我需要我的关键字段作为其他表中的外键。无论如何,由于支持按位运算符,现在这一点没有实际意义。我的结构变得明显。
    • 嗯...无论您从何处获取关键值,它们都同样有用。而且我不明白“......因为支持按位运算符......”你的意思是因为现在你可以,你必须?对不起,但我没有遵循你的论点。但我相信你的结构会变得很明显。
    • 我的主数据字段涉及连接表(用于多对多关系)。如果这些数据不在数据库中,我该如何使用它们?您不遵循我的论点的原因是因为我还没有提出论点!只是我现在对使用我原来的计划充满信心。
    • 澄清:大概任何布尔选择机制都会为您提供用作其他表的“外来”键的键。但祝你好运! (只有 1K 条记录的索引和基数希望是无关紧要的。)
    【解决方案2】:

    为什么不能使用位运算符?

    &   bitwise AND 91 & 15 11
    |   bitwise OR  32 | 3  35
    #   bitwise XOR 17 # 5  20
    ~   bitwise NOT ~1  -2
    

    来自:http://www.postgresql.org/docs/7.4/static/functions-math.html

    我认为您可以将它们分成更小的组,但除此之外我不知道其他方式。

    【讨论】:

    • 我可以使用它们。这很尴尬。
    【解决方案3】:
    【解决方案4】:

    为最适合您的问题领域的数据建模。您在这里没有太多数据,在最坏的情况下,假设每行占用 200 个字节,您看到的数据少于 200 Kb。即使您的特定数据库没有以有效的方式实现布尔属性,这也是微不足道的。

    另一方面,拥有 150 个布尔属性听起来有些可疑,也许您的数据模型可以进一步规范化?

    【讨论】:

    • 大小不是我关心的问题,尽管我同意 150 个属性是可疑的。规范化位域和创建额外的连接表是不值得的,因为位域没有其他属性。无论如何,我已解决的对位运算符的无知使我的问题无效。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多