MySQL - автоинкремент + составной первичный ключ - производительность и целостность

Question

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

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

Вот некоторые псевдо-код, показывающий общую компоновку:

CREATE TABLE Item (
id AUTO_INCREMENT, 
... 
PRIMARY KEY (id) 
) ENGINE = InnoDB; 

CREATE TABLE PriceCategory (
id AUTO_INCREMENT, 
... 
PRIMARY KEY (id) 
) 

CREATE TABLE ItemPriceCategory (
itemId, 
priceCategoryId, 
id AUTO_INCREMENT, 
... 
UNIQUE INDEX id, 
PRIMARY KEY (eventId, priceCategoryId) 
) 

CREATE TABLE ClientType (
id AUTO_INCREMENT, 
... 
PRIMARY KEY (id) 
) 

CREATE TABLE Price (
itemPriceCategoryId, 
clientTypeId, 
id AUTO_INCREMENT, 
... 
UNIQUE INDEX id, 
PRIMARY KEY (itemPriceCategoryId, clientTypeId) 
) 

table Purchase (
priceId, 
userId, 
amount, 
PRIMARY KEY (priceId, userId) 
) 

Названия таблиц были изменены, чтобы защитить невинных ;-) Кроме того, фактическое расположение немного глубже в плане ссылок.

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

Заранее спасибо.

Answer 1

Как правило, советы по первичным ключам состоят в том, чтобы иметь «бессмысленные» неизменные первичные ключи с одной колонкой. Автоматически увеличивающиеся целые числа хороши.

Итак, я бы отменил ваш дизайн - ваши таблицы соединений также должны иметь бессмысленные первичные ключи. Например:

CREATE TABLE ItemPriceCategory (
itemId, 
priceCategoryId, 
id AUTO_INCREMENT, 
... 
PRIMARY KEY id, 
UNIQUE INDEX (eventId, priceCategoryId) 
) 

Таким образом, колонна itemPriceCategoryId в цене надлежащего внешнего ключа, ссылки на первичный ключ ItemPriceCategory таблицы.

Вы можете использовать http://dev.mysql.com/doc/refman/5.5/en/innodb-foreign-key-constraints.html внешние ключи, чтобы обеспечить согласованность базы данных.

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

Answer 2

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

В общем, есть два подхода. Первый заключается в распространении ключей, а второй - в том, что для каждой таблицы должно быть значение auto-increment integer как PK.

Второй подход часто обусловлен ОРМ инструментами, которые используют DB в качестве хранилища объектно-персистентности, в то время как первый (с помощью ключа распространения) является более общим для ручного DB дизайна.

В целом модель с распространением ключей обеспечивает лучшую производительность для «случайных запросов», главным образом потому, что вы можете «пропускать таблицы» в соединениях. Например, в модели с распространением ключа вы можете присоединиться к таблице Purchase непосредственно к таблице Item, чтобы сообщить о покупках по ItemName. В другой модели вам придется присоединиться к Price и ItemPriceCategory таблицам тоже - только для того, чтобы добраться до ItemID.

В принципе, модель с распространением ключей по существу является реляционной - в то время как другая управляется объектами. Инструменты ORM либо предпочитают, либо обеспечивают исполнение модели с отдельным идентификатором (второй случай), но предлагают другие преимущества для разработки.

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

---

С ключом распространения

---

Независимые ключи для каждой таблицы