标签: inheritance

我正在创建一个概念图 [是的，我知道我已经包含了属性和键 - 但这只是让我在学习的同时巩固我正在做的事情] - 所以请把它当作概念性的，重点是关系和表格而不是如何绘制图表；)

我的障碍是： 我正在尝试确定对配置文件、位置和组织关系进行建模的最佳方式。

首先，规则：

• One or more Profile's can be a Member/Friend of one or more Organizations; and vice versa.
• One or more Profile's can be a Member/Friend of other Profiles.
• One or more Organization's can be a Member/Friend of other Organizations.

Friend and Member differ, in that, Friends are like read-only and Members [depending on level] have full access to amend things.

更复杂的是，位置有自己的一套“进一步”细化规则，例如一个组织拥有两个位置，但根据位置规则，该组织的成员 [ …

好的，设置场景。我有三个表，（ Table1，Table2和DataTable），我想插入Table1和Table2使用DataTable作为源。因此，对于每一行，DataTable我都希望在Table1and 中有一排Table2，并且Table2需要id从Table1...插入（PK）

如果我要这样做...

INSERT INTO Table1 SELECT A, B, C FROM MyTable
INSERT INTO Table2 SELECT IDENTITY_INSERT(), D, E, F FROM MyTable

我将ID最后插入的记录的Table1.

是CURSOR或WHILE循环来做到这一点的唯一途径？

我有一个带有主表和 2 个子表的 PostgreSQL 数据库。我的主表：

CREATE TABLE test (
    id serial PRIMARY KEY, 
    date timestamp without time zone
);
CREATE INDEX ON test(date);

我的子表：

CREATE TABLE test_20150812 (
    CHECK ( date >= DATE '2015-08-12' AND date < DATE '2015-08-13' )
) INHERITS (test);

CREATE TABLE test_20150811 (
    CHECK ( date >= DATE '2015-08-11' AND date < DATE '2015-08-12' )
) INHERITS (test);

CREATE INDEX ON test_20150812(date);
CREATE INDEX ON test_20150811(date);

当我执行查询时：

select * from test_20150812 where date > '2015-08-12' order …

我不确定这是否适合这个地方，所以请随时告诉我它是否偏离主题或有更好的发帖地方。

我正在做一个基于幻想体育的项目，桌子的数量越来越多。我有诸如nba_players,nfl_players等和nba_players_to_teams,nfl_players_to_teams等表（NBA 和 NFL 分别是篮球和美式橄榄球联盟）。这些都共享相同的表模式和代码库，但在不同的表上有它们的外键。

我的问题是，在这种情况下使用表继承有意义吗？“基”表将是空的，仅用于强制执行模式。对“基”表的更改会传播到从它继承的表吗？在这一点上，模式非常稳定，所以这不是一个大问题。

有没有我没有解决的想法或疑虑？我仍在阅读有关表继承及其优缺点的文章，但您拥有的任何资源都将不胜感激。

我有一个带有主表和 2 个子表的 PostgreSQL 9.0.12 数据库。我的表：

CREATE TABLE test2 (
    id serial PRIMARY KEY,
    coll character varying(15),
    ts timestamp without time zone
);
CREATE INDEX ON test2(ts);

CREATE TABLE test2_20150812 (
    CHECK ( ts >= timestamp '2015-08-12' AND ts < timestamp '2015-08-13' )
) INHERITS (test2);

CREATE TABLE test2_20150811 (
    CHECK ( ts >= timestamp '2015-08-11' AND ts < timestamp '2015-08-12' )
) INHERITS (test2);

CREATE INDEX ON test2_20150812(ts);
CREATE INDEX ON test2_20150811(ts);
VACUUM FULL ANALYZE;

我的选择查询的解释结果（数据库中没有任何行）：

EXPLAIN (ANALYZE, BUFFERS) …

我是 PostgreSQL 的新手。我遇到的情况是有人创建了一个从父表继承的子表。并丢弃了子表。但是父表上仍然有“向下箭头”标志。

我检查过，父表上没有其他链接/关系。这真的是个问题吗？

有人告诉我，父表仍处于“已继承”状态并导致性能问题。如何解决这个问题？通过从父表中删除“已继承”状态？

要在 postgres 中强制执行部分唯一性，创建部分唯一索引而不是显式约束是一种众所周知的解决方法，如下所示：

CREATE TABLE possession (
  possession_id serial PRIMARY KEY,
  owner_id integer NOT NULL REFERENCES owner(owner_id),
  special boolean NOT NULL DEFAULT false
);
CREATE UNIQUE INDEX possession_unique_special ON possession(owner_id, special) WHERE special = true;

这将限制每个所有者在数据库级别拥有不超过一个特殊财产。显然，创建跨多个表的索引是不可能的，因此在列存在于不同表中的超类型和子类型情况下，此方法不能用于强制执行部分唯一性。

CREATE TABLE possession (
  possession_id serial PRIMARY KEY,
  owner_id integer NOT NULL REFERENCES owner(owner_id)
);

CREATE TABLE toy (
  possession_id integer PRIMARY KEY REFERENCES possession(possession_id),
  special boolean NOT NULL DEFAULT false
);

如您所见，在此示例中，较早的方法不允许将每个所有者限制为不超过一个特殊玩具。假设每个财产都必须实现一个子类型，那么在不大量改变原始表的情况下在 postgres 中强制执行此约束的最佳方法是什么？

我有两张表，一张继承了另一张：

CREATE TABLE parent (
    col1 INTEGER
);

CREATE TABLE child (
    col2 INTEGER
) INHERITS( parent );

// Insert some data
INSERT INTO parent( col1 ) VALUES( 1 );
INSERT INTO child( col1, col2 ) VALUES( 2, 2 );

有什么方法可以查询父表，使其获取子表的所有列？

此查询仅返回父列：

SELECT * FROM parent;

| col1 |
| ---- |
| 1    |
| 2    |

我想要的查询将返回父和子中的所有列：

SELECT ...  -- some query, with desired result:

| col1 | col2 |
| ---- | ---- |
| 1    | …

我正在开发一个简单的保姆应用程序，它有两种类型的用户：“父母”和“保姆”。我使用 postgresql 作为我的数据库，但我在设计我的数据库时遇到了麻烦。

'Parent' 和 'Babysitter' 实体具有可以概括的属性，例如：用户名、密码、电子邮件……这些属性可以放置在名为“用户”的父实体中。它们也都有自己的属性，例如：Babysitter -> age。

就 OOP 而言，事情对我来说非常清楚，只需扩展用户类就可以了，但在 DB 设计中，情况有所不同。在发布这个问题之前，我在互联网上漫游了一周，以寻找对这个“问题”的洞察。我确实找到了很多信息，但
在我看来，有很多分歧。以下是我读过的一些帖子：

/sf/ask/13320751/ : Table-Per-Type (TPT), Table-Per-Hierarchy (TPH) 和 Table- Per-Concrete (TPC) VS '将 RDb 强制转换为基于类的需求是完全不正确的。

多种用户类型 - 数据库设计建议：

Table: `users`; contains all similar fields as well as a `user_type_id` column (a foreign key on `id` in `user_types`
Table: `user_types`; contains an `id` and a `type` (Student, Instructor, etc.)
Table: `students`; contains fields only related to students as well as a `user_id` column (a foreign key …

这似乎是一个很常见的场景：几种类型都构成相同的子类型。

这通常看起来像这样：

-- 'name' is unique per parent record
CREATE TABLE sometype (
  sometype_id serial PRIMARY KEY,
  name        text
);

CREATE TABLE foo (foo_id serial PK);
CREATE TABLE bar (bar_id serial PK);

CREATE TABLE foo_sometype (
  foo_id      int4,
  sometype_id int4
);

CREATE TABLE bar_sometype (
  bar_id      int4,
  sometype_id int4
);

这很好，但查询起来很麻烦。我认为这可能更清洁：

-- 'name' is unique per parent record
CREATE TABLE sometype (
  name        text
);

CREATE TABLE foo_sometype (
  foo_id      int4
) INHERITS(sometype);

CREATE TABLE bar_sometype (
  bar_id      int4,
) …