Какую структуру БД выбрать для рейтинга?

Question

[Max Ba]

Всем привет. Разрабатывается система голосований (для рейтинга). Проект рассматривается на перспективу. Суть: есть около 100 мероприятий и будет (к примеру) 10.000 посетителей. Каждый посетитель может поставить определенный бал каждому мероприятию. От -100 до 100. (INT)
Следовательно сам вопрос: правильно ли я выбрал структуру БД и не будут ли нас ждать неприятные сюрпризы в будущем?
Таблица голосований: `id`, `user`, `item`, `val`. Тип таблиц InnoDB, столбцы все INTEGER
`id` первичный ключ.
`user` внешний ключ к таблице "пользователей"
`item` внешний ключ к таблице "мероприятия"
`val` Значение голоса TINYINT. от -100 до 100.

Будет ли всё это работать без сбоев, при условии, что будет около 1.000.000 строк?

Выборка: SELECT * FROM `tab` WHERE `item` = 1000... и далее в массив.

Comments

[Max Ba]

Кстати мужики, а еще вопрос, сюда же. Не стал дописывать, тк думал не принципиально.
В этой системе несколько необычный вид голосования. Один человек голосует сразу за 10-20 мероприятий. Он также может переголосовать через какое-то время. Следовательно, чтобы не делать проверку массивом и заменами, проще очистить таблицу от голосов ЭТОГО юзера и записать на новые строки новые результаты. Лично я вижу проблему только в расходовании ID (честно, не очень понимаю зачем вообще это поле, тк обычно ему применение самое основное, в данном случае оно лишне, но дабы делать КАК НУЖНО сделал), но не думаю что это критичная проблема. Может я еще чего не подозреваю?

[1 2]

очищать тоже немалый труд!!))

[hubramubr]

> только в расходовании ID
это не проблема.

Answer 1

[skyfortress]

Вроде все правильно, а 1 000 000 при вашей структуре это совсем немного.

Answer 2

[nelson]

Структура нормальная. Говорю как человек, который использует такую же более чем на 10 миллионах строк с голосами.
Единственное, я бы делал запрос на выборку голосов не select * , а select user,val ведь id его голоса нам не нужен, а item у всех строк одинаковый. Ну, и пересчитывал бы рейтинг мероприятия всё таки при каждом голосовании, а не при просмотре результатов (хотя это зависит от того, что будет происходить чаще).
И чтобы проверять, гословал ли данный юзер за данное мероприятие, не помешает еще составной индекс по (user,item).

Comments

[romy4]

всё правильно. лучше агрегировать данные сразу

[Max Ba]

Но я и так, перед вставкой, делаю запрос SELECT на наличие записи. При этом не будет лишнего индекса. Или он нужен?

[Анатолий Евладов]

Соглашусь, но дополню что сам бы еще добавил время голосования и информацию о клиенте с которого голосование шло.
Можно даже в отдельной таблице сделать, хотя IP+время я бы добавил в основную.
А то боты они такие боты...

[nelson]

maximka787: "Но я и так, перед вставкой, делаю запрос SELECT на наличие записи." Вот для такой проверки составной индекс и нужен. Просто работать будет быстрее (за счет того что оно не полезет в саму таблицу, а сделает только index lookup). Если скорость работы не критична, а критична скорость вставки или же место на диске - то составной индекс можно не делать.