Какой индекс будет оптимальнее?

Question

[Андрей Суржиков]

Подскажите, пожалуйста, как лучше сделать индекс.
Строю систему для менеджмента спортивных мероприятий. Нужно на начальном этапе определиться с индексами.

Система многопользовательская
Итак есть
user - пользователь системы
event - спортивное мероприятие (у каждый пользователь может создать неограниченное число мероприятий)
competitors - участники мероприятий (в каждом мероприятии может быть сколько угодно участников)
splits - Сплиты участников (время пересечения отсечек на спортивной дистанции, у каждого участника сколько угодно сплитов)

Получается что в одном мероприятии может быть около 10 000 сплитов. А мероприятий может быть 10 в день.

Я хочу добавить в каждой таблице UUID Primary и составной индекс (event_id + id)
Подскажите, это верный подход?
Возможно стоит отказать от UUID и использовать в качестве Primary составной индекс из event_id+id (обычные числовые автоинкременты) ? Возможно надо не париться и просто использовать один числовой автоинкрементируемый ID?

Хочется, чтобы в пределах каждого мероприятия у участников и сплитов ID-шники начинались снова с единицы.

Подскажите, кто разбирается, а то такие знания только с опытом приобретаются..

Comments

[Stalker_RED]

Хочется, чтобы в пределах каждого мероприятия у участников и сплитов ID-шники начинались снова с единицы.

Но зачем?

[Алексей]

Сделайте сначала без индексов, потом прогоните через EXPLAIN те запросы, которые используются в коде и будет понятно какой куда вешать. Думаю я бы сделал так:
таблица users (user_id как ПК)
таблица event (event_id как ПК)
промежуточная таблица competitions (event_id, user_id как ПК составной реляционной модели)

Я, к сожалению, не знаю что такое сплиты. А по поводу, чтобы ИД начинались с 1, ну создайте еще один столбец в таблицу компетишена с названием custom_id.

[Андрей Суржиков]

Stalker_RED:
например, чтобы в роутинге /event/{event_id}/split/{split_id}
не было такого, что /event/4/split/993874 - на самом деле - это первый сплит в системе.

Answer 1

[coderlex]

Подскажите, это верный подход?

Это целиком зависит от запросов и их частоты. Хотябы оценочной по вашим прикидкам. Говорить что-то конкретное без подобной информации по этому поводу бесполезно. Если делать по уму, то для точного ответа нужна будет ещё и статистика. Заполните базу mock-данными, проидитесь по логам трассы и оцените, где нужны дополнительные индексы, а где только помешают. Не забывайте, выделение индекса - операция ресурсоемкая.

Answer 2

[Константин Цветков]

Хочется, чтобы в пределах каждого мероприятия у участников и сплитов ID-шники начинались снова с единицы.

Пронумеровать участников — это понятно и необходимо (или присвоить им постоянные номера). Пронумеровать мероприятия тоже нужно (этап 10 — понятно). А вот сквозная нумерация отсечек — совершенно не информативно — нумеровать их нужно для каждого участника отдельно, например, 85.25 — участник №85, отметка №25.
Да, соответственно, нумерацию записывать в отдельное, не ключевое поле, триггерами (отслеживать непрерывность нумерации ими же). Можно наложить уникальность в нужных диапазонах.

Comments

[Андрей Суржиков]

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

[Константин Цветков]

Я написал так условно: чтобы понять подход.

Подход простой: архитектура данных — постройка модели физической сущности и нормализация, полученных из неё плоских таблиц. Если вам нужна нумерация — добавьте её в модель.