Хорошая практика иметь несколько внешних ключей в одном столе?

Рассмотрим следующую структуру таблицы:Хорошая практика иметь несколько внешних ключей в одном столе?

titles(titleID*, titleName) 
platforms(platformID*, platformName) 
products(platformID*, titleID*, releaseDate) 
publishers(publisherID*, publisherName) 
developers(developerID*, developerName) 
products_publishers(platformID*, titleID*,publisherID*) 
products_developers(platformID*, titleID*, developerID*)

В таблице продуктов представляет собой таблицу, краснодеревщик с использованием двух внешних ключей platformID и titleID. Это связано с тем, что некоторые заголовки имеют одинаковые атрибуты на разных платформах. Чтобы избежать повторения данных, я создал таблицу столяра.

Мой вопрос возникает, когда я создаю таблицу products_publishers. Поскольку у одного продукта может быть несколько издателей, мне нужно создать столярную таблицу из трех внешних ключей. Это лучшая практика? Мой сценарий мог создать таблицу с четырьмя такими элементами. Я рассмотрел использование столбца для хранения этих данных в таблице продуктов и отказался от таблицы столяра и таблицы издателя, но интуитивно это не кажется правильным.

Любые мысли?

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

источник

2010-02-19 Mohamad

-1: Не могли бы вы объяснить, почему вы подозреваете, что наличие нескольких внешних ключей на одном столе может быть плохим? –

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

Это вполне нормально и относится к составным клавишам. Еще одна распространенная стратегия, которую я видел, - также предоставить таблице первичный ключ (суррогатный ключ), как и все остальные таблицы. Некоторые из причин для выполнения:

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

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

источник

2010-02-19 13:06:16

Большое спасибо, я буду использовать суррогатный ключ в моей таблице продуктов. Я вижу, что преимущество в плане производительности само по себе стоит того. – Mohamad

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

источник

2010-02-19 12:50:33

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

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

источник

2010-02-19 12:55:44 chros

Согласен. Во многих проектах мы используем 2-3 внешних ключа в некоторых таблицах. Он отлично работает, и я не могу придумать лучшего решения для многих реляционных проблем - и я никогда не видел его.

источник

2010-02-19 13:00:55

Хорошая практика иметь несколько внешних ключей в одном столе?

ответ

Смежные вопросы