【问题标题】:Storing all the data in one postgres table with partitioning将所有数据存储在一个带有分区的 postgres 表中
【发布时间】:2022-10-13 20:51:30
【问题描述】:

我看到了一些不寻常的数据库设计,需要一些帮助来理解挑战。

设计是

  1. DB 是 Postgres
  2. 人力资源应用程序所需的所有数据——来自员工数据、时间表、发票等的数据都存储在一个表中
  3. 该表有 EntityType 、ID、Data (jsonb ) 列。该表按实体类型进行分区。

    将所有数据放在一个带有分区的表中,好的设计吗?

    我们将面临哪些挑战?

    我们每周查看 50 万条新记录。

【问题讨论】:

  • 请提供足够的代码,以便其他人可以更好地理解或重现该问题。
  • 您描述的似乎是实体-属性-值(EAV)模型。恕我直言,这是一个绝对可怕的数据模型.其他人不同意。你应该用谷歌搜索它,熟悉它,建立一个测试集(比如 M:M 关系),然后做出你自己的决定。
  • "员工数据、时间表、发票等存储在一个表中“那是一个可怕的数据库模型。所以,不,这不是一个好的设计。

标签: postgresql jsonb


【解决方案1】:

此模式称为 EAV(实体属性值),有时称为 OpenSchema,但在数据库反模式中也称为数据库,在某些博客文章中称为 EAVil 模式。人们想使用它的原因是它在扩展模式方面提供的灵活性。

您现在插入的行数可能已经或很快会导致检索数据时出现严重的性能问题,尽管我还没有尝试过分区。我仍然相信这些 EAV 不会像常规规范化模式那样扩展。

除了查询更难在 EAV 模式上编写之外,您正在使所有值无类型(除非在此方面花费大量精力),不可索引,数据约束将更难或不可能,因此数据完整性存在风险(年龄:-30 )等等等等

如果您想要一个好的概述和一个好的建议,请阅读 Bill Karwins 的书 SQL Antipatterns,他写了几页关于 EAV 主题的文章。此外,来自 Oracle 的 Tom Kyte 是反对 EAV 的强烈倡导者,还有许多其他人,他们的批评也站得住脚。关系数据库不适合这种模式,您应该使用普通表。

【讨论】:

    猜你喜欢
    • 2023-02-15
    • 1970-01-01
    • 2013-04-20
    • 1970-01-01
    • 1970-01-01
    • 2019-03-07
    • 1970-01-01
    • 1970-01-01
    • 2021-07-28
    相关资源
    最近更新 更多