Несколько столбцов FK, все указывают на одну и ту же родительскую таблицу - хорошая идея?

Question

Для тех из вас, кто живет и дышит проектированием баз данных, вы когда-нибудь находили убедительные причины иметь в таблице несколько FK, которые все указывают на одну родительскую таблицу?

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

Большое спасибо.

Answer 1

Многое зависит от ситуации. Бывают моменты, когда вам нужно это сделать, а иногда требуется редизайн. Первое хорошее использование, которое приходит на ум, - это система обмена сообщениями для веб-сайта, где поля user_to и user_from будут указывать на user_id в таблице users.

Хотя для 6, указывающего назад, я бы подумал, что что-то нужно изменить, но не зная специфики, невозможно сказать.

Answer 2

Это действительно не может быть проанализировано в вакууме (то есть, не видя требований). Главное - выяснить, связаны ли эти 6 частей данных друг с другом.

Набор столбцов, такой как: Item1, Item2, Item3, очевидно, будет делать это неправильно (используйте таблицу соединений), но если значения каждого столбца не связаны друг с другом, то все в порядке, даже если оно выглядит немного странно.

Answer 3

Ну, может быть таблица IMO с такими столбцами, как:

Владелец, CreatedBy, LastModifiedBy, AcceptedBy, ProposedBy, который может указывать на одну таблицу пользователя

Answer 4

Иногда мы делаем это, когда PK предназначен для таблицы person, и нам нужно хранить сведения о двух разных классах людей в одной таблице. Если бы шесть столбцов представляли собой закономерно различную информацию (и вряд ли расширились бы до семи столбцов позже), это могло бы быть хорошо, но больше, чем два, и я бы посмотрел, была ли связанная таблица действительно необходимой.

Answer 5

Таблица Persons {personID otherpersonattributes ...} Таблица InterPersonRelationships {personID1 personID2 тип связи}

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

Answer 6

Имея базу данных интернет-магазина, должна быть одна таблица с адресами и одна таблица с заказами - теперь в заказе есть две таблицы адресов для таблицы адресов, одна из которых содержит адрес доставки, а другая содержит ключ адресов выставления счетов.

Answer 7

У меня есть несколько примеров нескольких FK между двумя таблицами.

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

Один пример, который вы часто видите:

Допустим, у меня есть таблица с ключевыми ID. У меня может быть дочерняя таблица с stuffID1, stuffID2 для захвата пар. Или тройки с 3 колонками FK.

Answer 8

Я не могу себе представить, почему вам нужно 6 полей, указывающих на одну родительскую запись ... звучит странно, как вы и думали Вы говорите «плохой дизайн с нашей стороны», ваша компания спроектировала стол таким образом?