Добрый день Товарищи!

Подскажите пожалуйста, есть ли смысл такой подход к решению хранения данных такого рода:

1. Есть сущность, и у этой сущности могут быть мероприятия.

И в запросах к этой сущности необходимо получать информацию о текущем (-их) мероприятиях, но в то же время иметь при необходимости получать список всей истории мероприятий у Сущности.

Так вот стоит ли делать 2 таблицы:



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

Какие минусы, проблемы или это вообще гон? :)

Жоско выглядит, сегодня опробую это непонятное партиционирование.
Спасибо!

Т.е. если условно есть поле isActive - то даже не смотря на то, что кол-во значений с isActive=0 будет стремиться к преобладанию, над isActive=1 - один фиг партиционирование стоит в таком случае использовать?

А принципиальное отличие от индекса по этому полю есть?

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

Век живи - век учись!

Только сразу ложечка дёгтя выяснилась:
авторForeign key clause is not yet supported in conjunction with partitioning

MariaDB 10.4.7

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

Akina,

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