Проектирование базы данных - выбор ключа для детей объединяемых таблиц

Question

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

У меня есть стол attendees и стол events,

Таблица соединения event_attendees, содержащий два внешних ключа attendee_id а также event_id, а также имеет суррогатный первичный ключ id

скажем, участники мероприятия могут иметь schedule_items,

Я обычно просто использовал бы столбцы event_attendee_id, schedule_item_id в таблице event_attendee_schedule_items,

Какие недостатки, если таковые имеются, будет иметь использование следующего составного внешнего ключа над вышеуказанным?

attendee_id, event_id, schedule_item_id (составной ключ вместо прямой ссылки на event_attendees Таблица)?

Answer 1

Я бы порекомендовал первый подход, если:

• стол event_attendees все еще требуется. Потому что, если у вас есть две таблицы соединения event_attendees а также event_attendee_schedule_items (что в принципе и получается, если вы используете второй подход), вы можете вводить противоречивые данные. Даже если вы можете гарантировать, что две таблицы синхронизированы (например, с помощью внешней программы, которая записывает данные), я бы не стал этого делать.

• у вас есть идеи других расширений в том же стиле, как таблица event_attendee_invoice_parts (который будет ссылаться на данные счета) вы можете поместить общие данные в event_attendees

• event_attendees имеет свои свойства, такие как entry_badge_id который будет использоваться в контексте event_attendee_schedule_items, По этим запросам вы должны присоединиться к event_attendees в любом случае.

Последняя причина дает нам дополнительную подсказку: это зависит от количества данных в таблицах и запросов, которые вы делаете! В некоторых случаях ваша производительность получит выгоду от составных ключей (и составных индексов), в других - нет. Смотрите этот вопрос для подробного обсуждения.