Question

如果将所有子表作为外键与层次结构中位于它们之上的所有表链接，有什么危害呢？我有一个包含6个查找表的位置组件：

大陆
国家/地区
地区
城市
社区
位置类型

显然，每个级别的位置都是上面的子级，所以它将是父键的外键，但是如果我将所有键同时键入它们会有什么危害，那就是我的cities表有：

城市表

continent_id（fk to continent）
country_id（fk to country）
region_id（fk to region）

vs只有'region_id-fk到地区'？

我在我的方式中看到的好处是，如果我必须查找一个大陆的城市，我可以直接从城市到大陆，而不是跳到区域然后是国家然后大陆，但当然我不确定缺点或是否这个影响表现还是其他什么？

这是一组表格。我有很多像这样的表，所以我试图理解这个概念，所以我可以用它来设计其他表，也可以在我的其他组件上设置超过6个查找表。

Answer 1

伤害发生在denormalization（又称重复）数据中。

如果您已经拥有FK链接，则在层次结构的最后一个表中重复这些链接意味着您正在重复数据，如果您需要更改它，则不会在多个位置进行更改。

此外，使用您的多FK方案，除非您添加更多检查约束，否则您最终可能会在city表（国家/地区与大陆不匹配）上出现不一致的数据。

Answer 2

@mikey - 抱歉，我认为我没有对其他答案发表评论的声誉 - 无论如何：

对于非规范化的单表方法，五（六？）列上的复合主键是否足够？

在决定单表非规范化或多表规范化方法之间的另一个考虑因素是，您为更高级别的实体存储了哪些附加属性？例如，您只是存储城市名称，还是您还想要纬度/经度对，电话拨号代码等等？您想要存储的属性越多，您在denormlised模型中获得的重复（以及相关的数据管理问题）就越多。

Answer 3

我通常不会以这种方式做传递外键。一般来说，这会导致许多额外的头痛和许多额外的问题机会。保持简单。我不认为这本身就是一个非规范化问题。这只是一个让事情易于管理的问题。请考虑以下事项：

CREATE TABLE employee (
    control code text primary key,
    date_of_birth date not null,
    ..,..
    id serial not null unique
);

CREATE TABLE wage_salary ( -- owners have drawings, not salaries, so this avoids nulls
    employee_id int not null references employee(id),
    wage_amt numeric not null,
    per_interval interval not null,
    primary key (employee_id)
);

CREATE TABLE reported_wages ( -- for tax purposes
    employee_id int not null references wage_salary,
    year int not null,
    reported_wages numeric not null,
    PRIMARY KEY (employee_id, year),
    FOREIGN KEY (employee_id) REFERENCES employee(id) -- unnecessary and troublesome
);

在许多情况下，额外的冗余外键可能会让您感到困惑。由于它被强制执行，因此请将其保留下来。

在每个子桌上使用外键给所有父母/祖父母等的利弊？

3 个答案: