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

Question

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

我还想知道以下内容：

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

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

3. 它在Postgresql数据库中常用吗？

4. 除了易用性之外，它比使用 FK 更好吗？

   除了

5. 是否应该与 in Reason 一起使用来存储在整个数据库中使用的通用和重复属性（例如 id、名称、时间戳等）

Answer 1

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

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

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

你的意思是重复数据？不。

Postgresql中常用吗
数据库？

据我所知，不知道，但公平地说，这并没有说太多。

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

是否应该合理地使用它
存储通用和重复的内容
贯穿始终的属性
数据库（例如 ID、名称、时间
邮票等）

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

就我个人而言，我不使用表继承，除非它解决了真正的问题。还有其他适合关系模型的方法，可以将类层次结构映射到表，这些方法对于许多用例来说效果更好或同样好。

Answer 2

在简单浏览了 mu 指出的教程后，

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

性能考虑可能正是发明该结构的原因。

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

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

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

我会远离它并使用 FK 的“正确”设计。 “易于使用”可能是这种继承技术的一个品质，只有当你足够表面地看待它时才存在。我预计表面之下会潜伏着许多令人不快的意外，例如本教程末尾记录的一些意外。据我了解，关于仍然允许重复行的键声明的一个对我来说只是一个杀手。我的意思是，允许重复的键，你能有多疯狂？

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

“它应该与 in Reason 一起使用吗？”

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

Answer 3

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

像这样的事情：

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、名称等。这种方法实际上只是节省了复制/粘贴。这可能不是一个巨大的节省，因为每个子表仍然需要有 PK、FK 和 PK。单独定义的索引。

这样做的缺点是，您无法在没有联合的所有表中按 name 进行查询。如果您尝试进行类继承，这可能是一个要求。

像具有员工子类的人员这样的东西可以更好地建模为具有公共数据的人员表和具有与人员一对一链接的“子类”数据的员工表。这应该表现得很好，因为你将通过 PK 加入。搜索将查询人员表，然后您可以对员工数据进行外连接（使用 NULL 来暗示人员与员工）。