【问题标题】:What are the pros and cons of using inheritance in a database在数据库中使用继承有什么好处和坏处
【发布时间】:2011-08-14 07:44:22
【问题描述】:

我正在用 Postgresql 设计一个数据库。我想知道使用继承的优缺点是什么。

我还想知道以下内容:

  1. 对数据库性能的影响(即插入、更新、删除、索引等)?

  2. 父/子是否意味着重复输入[内部]?

  3. 在Postgresql数据库中常用吗?

  4. 除了易用性之外,它比使用 FK 有哪些更好的地方?

  5. 是否应该合理地使用它来存储在整个数据库中使用的通用和重复属性(例如 id、名称、时间戳等)

【问题讨论】:

  • 您的意思是在应用程序代码中使用表之间的关系和对象之间的继承?
  • @Satadru:PostgreSQL 在数据库中支持table inheritance

标签: database database-design postgresql inheritance relational-database


【解决方案1】:

对数据库性能的影响(即 插入、更新、删除、索引等)?

影响不大,因为达到相同结果的其他技术也会对性能产生影响。

父/子是否意味着重复 输入[内部]?

您的意思是重复数据?没有。

在Postgresql中常用吗 数据库?

我不知道,但公平地说,这并没有说那么多。

它比使用 FK other 更好吗? 比易用性? 它的有用性应根据具体情况确定。我个人只将它用于分区表。当它使其他事情变得困难时,它的易用性可能具有欺骗性。例如,约束不适用于整个父表和子表,而仅适用于定义它们的表,因此唯一约束可能无法满足您的要求。

是否应该与 in reason 一起使用 存储通用和重复 贯穿始终的属性 数据库(例如 id、name、time 邮票等)

我认为这不是一个好主意。继承关系应该是有意义的,如果它只是用来为你节省一点工作,现在只会让你和其他人感到困惑。

我个人不使用表继承,除非它解决了真正的问题。还有其他适合关系模型的方法将类层次结构映射到表,这些方法在许多用例中工作得更好或同样好。

【讨论】:

  • 我必须同意你的观点,它会混淆其他用户以及其他框架(尤其是 Django)。
【解决方案2】:

我已经成功使用了表继承,但是只针对很多表需要的通用属性,而不是“类”继承。

类似这样的:

CREATE TABLE base (
  uuid UUID NOT NULL DEFAULT uuid_generate_v4(),
  name VARCHAR(320) NOT NULL,
  updated_by UUID NOT NULL DEFAULT uuid_nil(),
  updated TIMESTAMP NOT NULL DEFAULT current_timestamp
);

CREATE TABLE child (
  childata TEXT NOT NULL DEFAULT '',
)
INHERITS (base);

我使用base 来保存许多表所需的数据。请注意,我实际上并没有将 anything 放在基表中(通过撤销所有权限强制执行)。每个子表都存储自己的 uuid、名称等。这种方法实际上只是节省了复制/粘贴。这可能不会节省很多,因为每个子表仍然需要单独定义 PK、FK 和索引。

这样做的缺点是您无法通过name 对所有没有联合的表进行查询。如果您尝试进行类继承,这可能是一项要求。

具有员工子类的人员可能更好地建模为具有公共数据的人员表和具有与人员一对一链接的“子类”数据的员工表。这应该表现得很好,因为您将通过 PK 加入。搜索将查询人员表,然后您可以对员工数据进行外部联接(使用 NULL 表示人员与员工)。

【讨论】:

    【解决方案3】:

    在看了mu指的那篇教程之后,

    “对数据库性能的影响(即插入、更新、删除、索引等)?”

    性能方面的考虑可能正是发明该构造的原因。

    “父/子是否意味着重复输入[内部]?”

    大概不会。它看起来更像是内部实现将基于诸如 ROWID() 之类的东西。如果我必须实现这样的功能,我会这样做,我怀疑任何 DBMS 工程师都会有不同的想法。

    “除了易用性之外,它比使用 FK 更好吗?”

    我会远离它并使用 FK 的“适当”设计。 “易用性”可能是这种继承技术的一种品质,只有在您足够肤浅地看待它时才存在。我预计会有许多令人不快的惊喜潜伏在表面之下,例如教程末尾记录的少数惊喜。据我所知,关于仍然允许重复行的关键声明对我来说只是一个杀手。我的意思是,允许重复的键,你能有多疯狂?

    我不这样做的另一个原因是我不确定这是否是标准 SQL。

    “是否应该与 in reason... 一起使用”

    如果键不再是唯一性声明,我唯一能想知道的就是所有原因都去了哪里。

    【讨论】:

      猜你喜欢
      • 2012-06-02
      • 2011-05-14
      • 1970-01-01
      • 2011-04-21
      • 2023-04-01
      • 2011-11-14
      • 1970-01-01
      • 2011-11-19
      • 2012-11-22
      相关资源
      最近更新 更多