【问题标题】:Design of DB table with many rows and many columns with binary information具有二进制信息的多行多列DB表设计
【发布时间】:2016-10-03 03:12:41
【问题描述】:

我们想在一个约 10^6 行的 sql 数据库中创建一个表。每个条目都有许多二进制属性(比如大约 30 个,每行只有几个属性集 True,大多数集 False)和一些整数属性(比如大约 5 个)。

如何设置这样的表?

具体来说,我应该在表中为每个属性(二进制或整数)设置一列,还是应该为整数属性和具有二进制属性的新表以及多对多关系创建列?或者还有其他更好/更清洁的选择吗?

我应该补充一下

  • 我们经常会查询具有给定属性组合的行,因此我们希望这些选择易于编写、干净且快速,

  • 我们会定期添加二进制属性

一个典型的条目看起来像,具有整数属性I 和二进制属性B

EntryID | I1 | I2 | B3 | B4 | B5 | B6 | B7 | B8 | B9 | ... | Bn
---------------------------------------------------------------
1234567 | 12 | 5  | 2  | F  | F  | F  | F  | T  | F  | ... | F 

【问题讨论】:

    标签: mysql sql many-to-many


    【解决方案1】:

    我建议不要有太多只有真/假值的列,而是使用整数类型列命名为“some_status”来替换一些具有相同类别的属性。例如 some_status = 10 代表活动,some_status = 20 代表非活动,some_status = 30 代表待定等。这可能有助于减少一些列。

    建议 2

    正如您所提到的,您将定期添加二进制属性,因此我建议您像下面这样设计您的数据库,以便您可以随时更新 Binary_property 表。

    对于只有少数二进制属性为真的情况,您可以考虑仅在 Entry_Binary_properties 表为真时添加这些二进制属性。以后选择时,如果Binary属性不在Entry_Binary_properties表中,默认为false。

    希望这会有所帮助。 =)

    【讨论】:

    • 感谢您的回答——我必须承认我不能完全相信这是设置数据库结构的正确方法。我还根据属性添加了一个关于查询的句子。你的建议让这很难做到。
    • 我知道它可能不适用于您的情况,也许您可​​以更新一些代码示例或二进制/整数属性,以便我们更容易为您解答。 =)
    • 在上面添加了一个建议2,希望它可以帮助您弄清楚您的数据库设计中的一些图像。 =)
    【解决方案2】:

    当你测试它时你就会知道它的性能。 jam in 测试您与虚拟数据放在一起的两个要点的数据最多需要两个小时。老实说,您的第一个项目符号点虚拟数据的生成时间比您的第二个项目符号要少得多。你将如何做到这一点将通过一组不同的大约 5000 行然后重复它们类似于上面的链接。这样一来,它就可以让您的索引保持诚实并接近现实生活的体验。

    立即想到的项目符号优点和缺点如下:

    您的第一个要点将从Covering Index(或多个)中受益匪浅。这意味着相比之下,您的 Read 查询会尖叫得更快。您可以从索引页“覆盖”的信息中受益,而无需从索引遍历到数据页。请注意,您的覆盖索引在您所称的所有二进制和整数列中都是可行的,因为它们很薄。

    根据您的查询,只有您自己知道,您还需要调查 Composite Indexes 又名多列索引。原因是,检索速度。

    Covering 和 Composite 之间的区别在于,尽管两者都位于多个列上,但 Covering 索引不需要访问数据页面来检索读取信息。

    另一方面,您对架构的任何regular 更改都需要使用alter table 语句和索引重新生成。在相对较小的 10^6 行表上。关于 10^9 不同的故事。

    到此结束对项目符号一的评论。

    当需要更改时,您的第二个要点(关联/联结/相交表)将受益于更理智的开发人员方法。但与第一个项目符号中使用的覆盖或综合指数策略相比,它的性能会受到影响。我估计检索的顺序会慢很多。只是一个猜测,值得一赌,不难测试。

    在任何一种情况下,只有您自己才能知道何时可以正确平衡索引选择,而这些索引选择绝不是免费赠品。随着检索速度的提高,插入/更新速度也很慢。

    【讨论】:

    • 谢谢@Drew 的回答,我必须玩和消化它,我会这样做!
    【解决方案3】:

    我遇到了类似的问题,并使用了交叉引用 (xref) 表。这是一个包含 2 个主键列的表,它们都是相关表的外键。

    CREATE TABLE Table1Table2Xref (
      Table1id INT foreign key references table1(Id),
      Table2id INT foreign key references table2(Id),
      info char(200),
      primary key (userid, userdataid),
    );
    

    【讨论】:

      猜你喜欢
      • 2011-11-06
      • 2020-03-01
      • 2021-10-16
      • 1970-01-01
      • 2020-11-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2022-09-28
      相关资源
      最近更新 更多