如何有效地实现父/子关系，其子继承父级属性

Question

我会尽量简化，但是如果你需要更多的信息，请告诉我。

我用的是Rails 4和PostgreSQL

编辑：

• 使用PSQL 9.3
• 数据集不会经常更改，对于这个特定的表，可能只有15列

我有一个设计，其中有一个“核心”components，其默认值如下：

• 材料=木材
• 颜色=蓝色
• 价格=1.52美元
• 尺寸= 3x2x5

这些“核心”components及其默认属性值由管理员管理，管理员可以根据需要通过管理界面进行调整。

用户可以创建一个新的component_group，它将预先填充可用的components。新组中的components都使用其“核心”component的默认属性值。

然后，用户可以修改组包含的任何components的属性值。

我目前所做的是:复制每个“核心”component，使用"core“的相同属性值创建一个新的唯一记录。

我担心的是，这个应用程序可能会创建大量的记录；其中许多记录可能不会更改其默认属性值。虽然我不确定，但这似乎最终将是一个性能问题(特别是当您考虑到在现实世界中，components将有他们自己的关系，这可能也需要重复)。

我最初的想法是实现某种系统，在这种系统中，只有在更改属性值时才创建新的component记录，否则component_group将引用“核心”component。

所以我的问题是：

1. 我目前的方法甚至是正确的吗？
2. 我的性能关注点是有效的，还是对DB不重要？
3. 这种类型的功能是否更适合NoSQL DB (如CouchDB )？
4. 这类功能是否有特定的名称？我看过Class-Table Inheritance / Multi-Table Inheritance，但我不认为这是我想要的。

Answer 1

您可以在子表中使用(大部分)相同的表定义和NULL值来默认为父行的相应列值。代码示例：

CREATE TABLE comp_template (  -- parent table 
  comp_template_id serial PRIMARY KEY
, material_id      int REFERENCES material
, color            enum
, ...           -- attributes may or may not be defined NOT NULL
);

CREATE TABLE comp_group (  -- container
  comp_group_id serial PRIMARY KEY
, comp_group    text NOT NULL
)

CREATE TABLE comp (  -- child table 
  comp_id          serial PRIMARY KEY
, comp_group_id    int NOT NULL REFERENCES comp_group ON UPDATE CASCADE
                                                      ON DELETE CASCADE
, comp_template_id int NOT NULL REFERENCES comp_template ON UPDATE CASCADE
, material_id      int REFERENCES material
, color            enum
, ...           -- like comp_template, but all attributes can be NULL

返回有效值的视图：

CREATE VIEW comp_effective AS
SELECT c.comp_id, c.comp_template_id
     , COALESCE(c.material_id, t.material_id) AS material_id
     , COALESCE(c.color, t.color) AS color
     , ...
FROM   comp c
JOIN   comp_template t USING (comp_template_id);

空存储是非常便宜的

• 可空列是否占用PostgreSQL中的额外空间？

这是假设您有一个小的、大部分是静态的可能属性集。该解决方案效率最高可达几百个不同属性(列)，在这些属性中，不需要每天添加另一个属性。否则，将寻找非结构化数据类型，如hstore或jsonb。

您可以使用comp_template和comp之间的继承，这是有意义的。但是，首先要考虑Postgres实现的局限性。

有关详细资料的答覆：

• 针对多列的hstore用例