Database 在数据库中使用继承的优缺点是什么

我正在用Postgresql设计一个数据库。我想知道使用继承的利弊

我还想知道以下情况：

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

父/子表示[内部]重复输入吗

它在Postgresql数据库中常用吗

除了易用性之外，它如何比使用FK更好

是否应合理使用它来存储整个数据库中使用的通用和重复属性（例如id、名称、时间戳等）

对数据库性能的影响（即。 插入、更新、删除、索引等）

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

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

你是说重复数据？没有

它在Postgresql中常用吗 数据库

据我所知不是这样，但公平地说，这并没有说明什么

它如何比使用FK other更好 而不是易用性？ 它的有效性应该根据具体情况来确定。就我个人而言，我只将其用于分区表。它的易用性会让其他事情变得困难，这可能是一种欺骗。例如，约束不作为一个整体应用于父表和子表，而仅适用于定义它们的表，因此唯一约束可能无法满足您的需要

它是否应与一起使用，以便 存储通用的和重复的 在整个过程中使用的属性 数据库（例如id、名称、时间） 邮票等）

我认为那不是个好主意。继承关系应该是有意义的，如果它现在只用于为您节省一点工作，那么它只会在以后混淆您和其他人

---

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

我已经成功地使用了表继承，但仅用于许多表所需的公共属性，而不是“类”继承

大概是这样的：

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

保存许多表所需的数据。请注意，我实际上没有在基表中放入任何内容（通过取消所有特权来强制执行）。每个子表存储自己的uuid、名称等。此方法实际上只保存复制/粘贴。由于每个子表仍然需要单独定义PKs、FKs和索引，因此这可能不会带来巨大的节省

这样做的缺点是，在没有联合的情况下，不能通过

name

跨所有表进行查询。如果您试图进行类继承，这可能是一个要求

---

类似于带有employee子类的person，可以更好地建模为带有公共数据的person表和带有“subclass”数据的employee表，该数据与person有1对1的链接。这应该表现得很好，因为你将通过PK加入。搜索将查询person表，然后您可以对员工数据进行外部联接（使用

NULL

表示person vs employee）。

在简要查看了mu所指的教程之后

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

性能方面的考虑可能正是发明这种结构的原因

“父/子项是否表示[内部]重复输入？”

大概不会。看起来内部实现更像是基于ROWID（）之类的东西。如果我必须实现这样一个特性，我会这样做，我怀疑任何DBMS工程师都会有不同的想法

“除了易用性之外，它如何比使用FK更好？”

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

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

“是否应该合理地使用它…”

---

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

你的意思是在应用程序代码中使用表之间的关系和对象之间的继承吗？@Satadru:PostgreSQL在数据库中的支持。我必须同意你的意见，它会混淆其他用户和其他框架（尤其是Django）。