2013-02-22 5 views
0

У меня есть сайт-член, на котором каждый пользователь может делать несколько ставок на футбольные игры каждый день. Идея состоит в том, чтобы суммировать точки каждого дня, вычислять их и отображать их на графике (используя API диаграммы Google). Все хорошо до сих пор. Каждый день новые точки будут вычисляться для каждого пользователя и отображаться на графике вместе с точками за прошедшие дни. Чтобы пользователь мог видеть свои прошлые результаты в кривой или графике. Мое единственное предположение - сделать таблицу с идентификатором - Username - Points - Round. Я не хочу, чтобы моя база данных страдала из-за моих плохо сконструированных таблиц и запросов.Сохранение истории точек в базе данных

Так что мой вопрос: как мне установить это в моей базе данных?

Это мой стол прямо сейчас:


Таблица -> ЧЛЕНЫ
ID
Firstname
Lastname
Имя пользователя Пароль

(Мой вымышленный стол).

Таблица -> MEMBERS_POINTS
ID

Имя пользователя Очки
Round


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

Найти сообщение here, но у меня не было никаких ответов, и у меня есть разные идеи.

EDIT

подмигнул член-сайт, где каждый пользователь, регистрирующий должен поместить все 60 ставок на этот раз, 60 ставок разделены из более чем 30 дней (которые я называю раунды). Каждый раунд состоит из 2 ставок, максимум 6 очков. Общий балл будет отображаться вместе с лидером вместе с победителем каждого дня. Каждый пользователь должен иметь возможность видеть свои прошлые оценки в виде графика.

1 пользователь = 60 ставок = 30 дней (раундов. Общее количество очков, и каждый пункт день хранится в записи.

+1

Я бы определенно имел поле datetime, представляющее, когда точки и раунд происходили в вашей таблице member_point, чтобы вы могли запрашивать по дням, по неделям, месяцам и т. Д. – legrandviking

+2

Как проходят раунды по дням? Может ли пользователь иметь несколько «игр» из 30 раундов?Вам действительно нужно объяснить, что отдельный дискретный объект, который вы хотите представить, и как они соотносятся друг с другом. Мне кажется, вам также нужны таблицы для ставок/действий в каждом раунде, а также хорошо? –

+1

Попробуйте объяснить в реальных условиях (например, что-то вроде «Приложение будет иметь любое количество членов, каждый участник может иметь много игр, каждая игра может иметь много раундов, каждый раунд может иметь X количество ставок/действий, каждый раунд займет 1 день, я хотел бы объединить баллы для каждого пользователя за игру, за раунд и/или ежедневно »). Основной отправной точкой может быть любой отдельный элемент, который у вас есть (пользователь, игра, раунд), который понадобится чтобы относиться к другим предметам в стиле «один-ко-многим» или «много-ко-многим», должен иметь свою собственную таблицу. –

ответ

2

Там есть пара вещей, здесь происходит.

Во-первых, вы озаботились (см. ниже) - базы данных очень хорошо справляются с большими объемами данных. В MySQL такой дизайн может вырасти до миллионов записей без каких-либо реальных проблем с производительностью

Во-вторых, проблема с дизайном. Вы действительно должны read up в дизайне базы данных - слишком большой ответ в одном вопросе - но ваша таблица member_points должна ссылаться на столбец member.id (при условии, что это первичный ключ), а не имя пользователя - если пользователь меняет свое имя пользователя, вам необходимо обновить все их записи member_points.

+0

спасибо! большой вклад в колонку id и структуру дизайна. – Handsken

Смежные вопросы