Выражение идентифицирующих и неидентифицирующих отношений в MySQL

Question

Контекст

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

Итак, три моих объекта:, и. Поскольку я хочу отслеживать шансы покемона на передвижение с течением времени, a находится в идентифицирующих отношениях с. Названия хода недостаточно для его идентификации, так как, например, ход «Karate Chop» отличается на 1, чем на 2. Таким образом, соответствующий первичный ключ в,, должен быть частью моего первичного ключа для.

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

Моя попытка

Итак, как мне написать это в MySQL? Я думаю, это будет что-то вроде

      CREATE TABLE move (
  moveID int NOT NULL,
  genID int NOT NULL,
  typeID int NOT NULL,
  PRIMARY KEY (MoveID, GenID),
  CONSTRAINT FK_GenMove FOREIGN KEY (genID) REFERENCES generation(genID),
  CONSTRAINT FK_TypeMove FOREIGN KEY (typeID) REFERENCES type(typeID)
);

Однако я не смог найти пример, где внешний ключ был частью первичного ключа в книге MySQL, которую я использую (они обсуждают идентификацию отношений, но я не смог найти пример с синтаксисом). В частности, я не уверен, имеет ли значение порядок, в котором перечислены ограничения (следует ли мне сначала объявлять свои первичные ключи, а затем внешние ключи?)

Индексы

Кроме того, я считаю, что составной первичный ключ автоматически станет кластеризованным индексом для моей таблицы. Обычный запрос - фильтрация move к generation/. Таким образом, это должно быть автоматически эффективным, поскольку у меня есть индекс, даже если он является частью составного ключа, верно? Или мне нужно сделать отдельный индекс для genID в одиночестве?

Answer 1

Одна вещь, которую я понял на следующий день, это то, что порядок, в котором я объявляю свой первичный ключ, имеет значение. (moveID, genID)будет сортировать по moveIDбудет первый genID, тогда как (genID, moveID)рассортировал бы по другому. Поскольку я упомянул, что мне нужно поведение последнего случая в моем исходном посте (выбрав все moveв данном generation), в отличие от предыдущего случая, я чувствовал, что должен указать.