Вопрос о дизайне ключей ключей сессий / журналов

Question

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

НоВопрос в том, что у меня есть такие столбцы: User_id (связать журнал сеанса или активности с пользователем) activity_id (связать таблицу активности журнала с таблицей поиска активности системы) session_id (связать таблицу журнала пользователя с родительским сеансом) ... иЕсть еще 4-5 столбцов.

Так что, если я не буду использовать FK, то как я "связываю" эти столбцы?Могу ли я присоединиться к таблицам и получить информацию о пользователе без ФК?Могу ли я написать правильные данные без ФК?Есть ли какое-то влияние на производительность или люди просто говорят и говорят, что это нет?

---

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

Answer 1

На самом деле, вы можете построить всю базу данных без реальных FKs в MySQL. Если вы используете MyISAM в качестве механизма хранения, FK в любом случае не реальны. Тем не менее, вы можете делать все объединения, которые вам нравятся, при условии, что ключи объединения совпадают.

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

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

AFAIK InnoDB в настоящее время является единственным, поддерживающим реальные внешние ключи (если MySQL 5.5 не получил новые или обновленные механизмы хранения, которые также поддерживают их). Механизмы хранения, такие как MyISAM, поддерживают синтаксис, но фактически не проверяют ссылочную целостность.

Answer 2

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

Проблема с FK в том, что они не хранят значение, а просто указатель на значение. Если значение изменяется, то история теряется. Вы НЕ ХОТИТЕ обновления, чтобы каскадно войти в ваш журнал истории. Это нормально, если у вас есть «поддельный внешний ключ», к которому вы можете присоединиться, но вы также намеренно хотите нормализовать соответствующие поля для сохранения истории.