Проблема с дизайном базы данных (или вопрос)

Question

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

Я использую регистр таблиц, чтобы зарегистрировать пользователя в игре.

Мне также нужно сохранить оценку пользователя в игре.

Мой вопрос:

Могу ли я добавить столбец называется счет в таблице зарегистрироваться? Это хороший дизайн?

Спасибо.

Answer 1

То, что вы описываете многие-ко-многим, используя REGISTER в качестве таблицы перекрестных ссылок:

USER 
UserID 

GAME 
GameID 

REGISTER 
UserID 
GameID 
Score 
[+ registration info] 

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

Отредактировано для добавления: Часто вам нужно будет сохранить историю игр («средний балл», «последние 5 игр», «самое быстрое время» и т. Д.). Затем у вас есть соотношение «один ко многим» между REGISTER и таблицей GAME_HISTORY.

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

Answer 2

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

Answer 3

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

Answer 4

Да, это хорошо оформленный дизайн. Но вы, вероятно, должны изменить название.

user: 
    userid 
    username 

game: 
    gameid 
    name 

usergame: 
    userid 
    gameid 
    score 

Answer 5

Если это таблица, следить за пользователем очков в различных играх: конечно, вы можете иметь этот столбец. Но, возможно, вместо этого назовите это «оценка»? (Если вам не нужна какая-то другая информация, возможно, вам следует использовать четвертую таблицу)

Answer 6

Думаю, вам стоит подумать о создании таблицы отношений.

UserId | GameId | Score 

UserId и GameId будет первичным ключом, а также каждый из которых чуждо таблиц User и Game соответственно.

Answer 7

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

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

Answer 8

Если цель вашей базы данных аналитики, то вы также будете считать это:

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

Это сделает ваши отчеты внутренними объединениями и поиск всех пользователей без регистрации прост и очевиден.