Архитектура БД: связь с пересечением или с основными таблицами?

Question

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

Таблица

Основной стол - Pool, в котором есть вся информация об управлении фэнтезийным проектом.

Стандартная таблица User, в которой содержатся обычные данные.

Таблица пересечений с именем pools_users, которая содержит id,pool_id,user_id, поскольку пользователь может находиться в более чем одном пуле, а пул содержит более 1 пользователя.

Проблема

Таблица Selections => это таблица, которая вызывает проблемы. Это выбор, который пользователь выбирает для своего пула. Это связано с таблицей Player, но это не относится к данной проблеме.

Должен ли я связать эту таблицу с таблицей Pools_users или связать ее как с основной таблицей Pool, так и с User. Эта таблица содержит id,pool_id,user_id,player_id,...

Как лучше всего связать мои таблицы? Когда я хочу получить свои данные, я обычно хочу, чтобы информация была разделена на пользователей. «У этого пользователя есть эти выборы, этот выбор и т. Д.).

Answer 1

Что такое бассейн? Это Лига, то есть группа команд, соревнующихся друг с другом? Причина, по которой я спрашиваю, заключается в том, что, похоже, у вас отсутствует сущность, т. Е. Команда ** (*) **.

В определенной степени это решение зависит от правил игры в фэнтези-футбол, в которой вы играете, но, по моему опыту, большинство игр позволяют пользователям участвовать в нескольких лигах («пулах»), но управлять только одной командой. Таким образом, между пользователями и командами существует один к одному. Когда мы смотрим на это таким образом, становится ясно, что выборы должны быть таблицей пересечений между командами (пользователями) и игроками.

Если ваш конкретный набор правил предписывает одну Группу для Пользователя, вам следует объединить две сущности в одну таблицу - которую я бы назвал Менеджерами, поскольку она лучше подходит для домена, но решение за вами;).

Answer 2

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

PS: если выборка содержит только игроков, то этот selection_ordinal_id вам не нужен как PK. Вы можете включить player_id в составной PK.

Answer 3

Я полагаю, что связал бы его с внешним ключом как для пулов, так и для пользователей (по pool_id и user_id соответственно). Выбор может иметь только один бассейн. Выбор может иметь только один пользователь.

Я мог бы использовать первичный ключ в таблице выбора, который выглядит следующим образом: pool_id, user_id, selection_id, поэтому 30-й выбор пользователем 123 в пуле 001 будет 001/123 / 30.

Будете ли вы обычно искать данные по пользователю или пулу и пользователю? Вы действительно распечатали бы все выборки пользователей независимо от пула? Если это так, вы можете подумать о перестановке первичного ключа так, чтобы он был user_id, pool_id, а затем selection_id. Это может ускорить поиск только по user_id, так как он сможет идти после первой части индекса первичного ключа.