Преимущество / недостаток использования внешних ключей на каждом дочернем столе для всех родителей / прародителей и т. Д.?

Question

Какой вред, если таковые имеются, чтобы связать все дочерние таблицы как внешние ключи со всеми таблицами над ними в иерархии? У меня есть компонент местоположения с 6 таблицами поиска:

• Континенты
• Страны
• Регионы
• Города
• Окрестности
• Тип местоположения

Очевидно, что каждый уровень местоположения является дочерним по отношению к вышеперечисленному, поэтому он будет использовать внешний ключ для родителя, но какой вред, если я добавлю все эти ключи вместе, то есть в таблице городов есть:

Городской стол

• continent_id (от ФК до материка)
• country_id (фк к стране)
• region_id (fk to region)

против только 'region_id-fk to region'?

Преимущество, которое я вижу на своем пути, заключается в том, что если мне нужно искать города на континенте, я могу переходить непосредственно из города на континент, не переходя в регион, страну, затем континент, но, конечно, я не уверен в недостатках или если это влияет на производительность или что-то еще?

Это один набор таблиц. У меня есть много таких таблиц, поэтому я пытаюсь понять концепцию, чтобы я мог использовать ее для разработки других таблиц, в том числе и для других моих компонентов, которые представляют собой нечто большее, чем 6 справочных таблиц.

Answer 1

Вред заключается в денормализации (дублирование) данных.

Если у вас уже есть ссылки FK, повторение их в последней таблице в иерархии означает, что вы повторяете данные, и если вам нужно их изменить, у вас не будет их в нескольких местах.

Кроме того, при использовании схемы с несколькими FK, если вы не добавите больше проверочных ограничений, вы можете получить противоречивые данные в таблице city (где страна и континент не совпадают).

Answer 2

Обычно я не делаю транзитивные внешние ключи таким способом.В целом это приводит к сильной головной боли и дополнительным возможностям для проблем.Держите вещи простыми.Я не вижу в этом самой проблемы денормализации.Это просто вопрос поддержания управляемости.Рассмотрим следующее:

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
);

В ряде случаев этот избыточный внешний ключ может вас укусить.Так как он применяется принудительно, отключите его.

Answer 3

@ Мики - извините, я не думаю, что у меня есть репутация, чтобы комментировать другой ответ - в любом случае:

Для денормализованного подхода с одной таблицей не будет ли составного первичного ключа в пяти (шести?) Столбцах достаточным?

Другое соображение при выборе между денормализованным или нормализованным подходом с несколькими таблицами заключается в том, какие дополнительные атрибуты вы сохраняете для сущностей более высокого уровня? Например, вы просто храните названия городов, или вам также нужны пары широта / долгота, телефонные коды и тому подобное? Чем больше атрибутов вы хотите сохранить, тем больше дублирования (и связанных с этим проблем управления данными) вы получите в денормализованной модели.