何时在PostgreSQL中使用继承的表？

Question 1

在哪些情况下应该使用继承的表？我试图非常简单地使用它们，并且在OOP世界中似乎没有继承。

我认为它像这样工作：

该表users具有所有用户级别所需的所有字段。表像moderators，admins，bloggers，等，但字段不从父检查。例如users具有电子邮件字段和继承bloggers现在已经太，但它不是唯一的两个users，并bloggers在同一时间。即。与我将电子邮件字段添加到两个表相同。

我只能想到的用法是通常使用的字段，例如row_is_deleted，created_at，modified_at。这是继承表的唯一用法吗？

Question 2

在postgres中使用表继承有一些主要原因。

可以说，我们有一些统计信息所需的表，每个月都会创建和填充这些表：

statistics
    - statistics_2010_04 (inherits statistics)
    - statistics_2010_05 (inherits statistics)

在此示例中，每个表中都有2.000.000行。每个表都有一个CHECK约束，以确保仅将匹配月份的数据存储在其中。

那么，什么使继承成为一个很酷的功能-为何拆分数据很酷？

性能：选择数据时，我们从x和Y之间的日期中选择* FROM statistics，而Postgres仅使用有意义的表。例如。选择*从统计信息中'2010-04-01'和'2010-04-15'之间的日期仅扫描表statistics_2010_04，所有其他表都不会被触及-快速！
索引大小：我们没有大的脂肪表，而该日期的脂肪指数也很大。我们每个月都有小表，索引也小-读取速度更快。
维护：我们可以在每个月表上运行真空完全，重新索引，集群，而无需锁定所有其他数据

要正确使用表继承作为性能增强器，请查看postgresql手册。您需要在每个表上设置CHECK约束以告知数据库，您的数据将在哪个键上进行分割（分区）。

我大量使用表继承，尤其是在存储按月分组的日志数据时。提示：如果存储永不更改的数据（日志数据），请使用CREATE INDEX ON（）WITH（fillfactor = 100）创建或索引。这意味着索引中不会保留更新空间-磁盘上的索引较小。

更新：fillfactor的默认值为100，来自http://www.postgresql.org/docs/9.1/static/sql-createtable.html：

表格的填充系数是10到100之间的百分比。默认值为100（完全打包）

Question 3

“表继承”的含义不同于“类继承”，并且它们具有不同的用途。

Postgres都是关于数据定义的。有时确实是非常复杂的数据定义。OOP（在一般的Java颜色意义上来说）是关于将行为从属于单个原子结构中的数据定义。“继承”一词的目的和含义在这里有很大的不同。

在OOP领域中，我可能会定义（此处的语法和语义非常宽松）：

import life

class Animal(life.Autonomous):
  metabolism = biofunc(alive=True)

  def die(self):
    self.metabolism = False

class Mammal(Animal):
  hair_color = color(foo=bar)

  def gray(self, mate):
    self.hair_color = age_effect('hair', self.age)

class Human(Mammal):
  alcoholic = vice_boolean(baz=balls)

表格如下所示：

CREATE TABLE animal
  (name       varchar(20) PRIMARY KEY,
   metabolism boolean NOT NULL);

CREATE TABLE mammal
  (hair_color  varchar(20) REFERENCES hair_color(code) NOT NULL,
   PRIMARY KEY (name))
  INHERITS (animal);

CREATE TABLE human
  (alcoholic  boolean NOT NULL,
   FOREIGN KEY (hair_color) REFERENCES hair_color(code),
   PRIMARY KEY (name))
  INHERITS (mammal);

但是这些行为在哪里呢？它们不适合任何地方。这不是数据库世界中讨论的“对象”的目的，因为数据库关注的是数据，而不是过程代码。您可以在数据库中编写函数来为您做计算（通常是一个很好的主意，但实际上并不适合这种情况），但是函数与方法并不相同，即您所谈论的OOP形式的方法故意降低灵活性。

关于作为一种原理性设备的继承，还有一点要指出：从Postgres 9.2开始，无法立即在所有分区/表族成员之间引用外键约束。您可以编写检查来执行此操作或以其他方式解决它，但是它不是内置功能（实际上归结为复杂索引的问题，而且没有人编写使该功能自动化的必要位）。除了为此目的使用表继承之外，数据库中对象继承的更好匹配通常是对表进行示意图扩展。像这样：

CREATE TABLE animal
  (name       varchar(20) PRIMARY KEY,
   ilk        varchar(20) REFERENCES animal_ilk NOT NULL,
   metabolism boolean NOT NULL);

CREATE TABLE mammal
  (animal      varchar(20) REFERENCES animal PRIMARY KEY,
   ilk         varchar(20) REFERENCES mammal_ilk NOT NULL,
   hair_color  varchar(20) REFERENCES hair_color(code) NOT NULL);


CREATE TABLE human
  (mammal     varchar(20) REFERENCES mammal PRIMARY KEY,
   alcoholic  boolean NOT NULL);

现在，我们有一个动物实例的规范引用，可以可靠地用作外键引用，并且我们有一个“ ilk”列，它引用了xxx_ilk定义表，该表指向扩展数据的“下一个”表（或表示如果ilk是泛型类型本身则不存在）。针对这种模式编写表函数，视图等非常容易，以至于大多数ORM框架在诉诸OOP样式类继承来创建对象类型族时，都会在后台执行此类操作。

Question 4

只要您不需要在父表上创建外键，就可以在OOP范式中使用继承。例如，如果您有一个抽象类车辆存储在车辆表中，并且继承了该表车，则所有车辆都将在车辆表中可见，但该车辆表上驾驶员表的外键与这些不匹配记录。

继承也可以用作分区工具。当您有要永久增长的表（日志表等）时，此功能特别有用。

Question 5

继承的主要用途是进行分区，但有时在其他情况下也很有用。在我的数据库中，有许多只外键不同的表。我的“抽象类”表“图像”包含一个“ ID”（主键必须在每个表中）和PostGIS 2.0栅格。继承的表（例如“ site_map”或“ artifact_drawing”）具有外键列（“ site_map”的“ site_name”文本列，“ artifact_drawing”表的“ artifact_id”整数列等）以及主键和外键约束；其余的则继承自“ image”表。我怀疑将来可能需要在所有图像表中添加一个“说明”列，因此这可以为我节省很多工作，而不会造成实际问题（嗯，

编辑：另一个很好的用法：通过对未注册用户进行两表处理，其他RDBMS在处理这两个表时会遇到问题，但是在PostgreSQL中很容易-只需ONLY在不中断继承的“未注册用户”表中的数据时添加即可。

Question 6

我对继承表的唯一经验是分配。它工作正常，但它不是PostgreSQL最复杂，最易于使用的部分。

上周，我们正在寻找相同的OOP问题，但是Hibernate存在太多问题（不喜欢我们的设置），因此我们在PostgreSQL中没有使用继承。

Question 7

当我在表之间具有多于一对一的关系时，我会使用继承。

示例：假设您要存储具有属性x，y，旋转，比例的对象图位置。

现在假设您有几种不同类型的对象要显示在地图上，并且每个对象都有自己的地图位置参数，并且永远不会重复使用地图参数。

在这些情况下，表继承对于避免必须维护未规范化的表或必须创建位置ID并将其交叉引用到其他表非常有用。

Question 8

尽可能少使用它。这通常意味着永远不会，它会沦落为一种创建违反关系模型的结构的方式，例如通过破坏信息原理并通过创建包而不是关系来实现。

而是将表分区与适当的关系建模（包括其他常规形式）结合使用。