Чтобы нормализовать или не нормализовать user_ids

Question

В моем приложении Rails у меня есть множество таблиц базы данных, содержащих пользовательские данные. Некоторые из этих таблиц в некоторых случаях содержат много строк (до 500 000 строк на пользователя) и часто запрашиваются. Всякий раз, когда я запрашиваю любую таблицу для чего-либо, user_id текущего пользователя находится где-то в запросе - либо напрямую, если таблица имеет прямую связь с пользователем, либо через соединение, если они связаны через некоторые другие таблицы.

Должен ли я денормализовать user_id и включать его в каждую таблицу для повышения производительности?

---

Вот один пример:

• Адрес относится к пользователю, и имеет user_id
• Конверт принадлежит пользователю, и имеет user_id
• AddressesEnvelopes присоединяется адрес и конверта, так он имеет envelope_id и address_id - он не имеет user_id, но может попасть в него через конверт или адрес (который должен принадлежать одному пользователю).

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

---

Вот другой сценарий:

• Письмо принадлежит пользователю, и имеет user_id
• этом получатель принадлежит к письму, и имеет letter_id
• RecepientOption принадлежит этом получатель, и имеет recepient_id

Имеет смысл дублировать user_id как у получателя, так и получателя Вариант, хотя я всегда мог добраться до него, пройдя через ассоциации, через Письмо?

---

Некоторые примечания:

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

---

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

Answer 1

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

user(
    #user_id 
) 
address(
    #user_id 
, #addres_num 
) 
envelope(
    #user_id 
, #envelope_num 
) 
address_envelope(
    #user_id 
, #addres_num 
, #envelope_num 
) 

(символ # указывает на столбец первичного ключа)

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

Еще одна вещь, которая имела бы смысл с этим типом дизайна используется кластеризованные индексы (в MySQL первичный ключ таблиц InnoDB построен из clu индекс). Если вы убедитесь, что user_id всегда является первым столбцом в вашем индексе, он гарантирует, что для каждой таблицы все данные для одного пользователя хранятся на диске вместе друг с другом. Это замечательно, когда вы всегда запрашиваете user_id, но это может повредить работу, если вы запрашиваете другой объект (в этом случае дублирование, как вы, сугест, может быть лучшим решением)

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

Answer 2

Пока вы

а) получить измеримое улучшение производительности

и

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

там нет причин не делать этого!

Answer 3

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

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

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