2009-11-16 2 views
29

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

В PHP и MySQL было бы ясно, что некоторые достижения заработаны немедленно (когда в случае SO с особым действием выполнено: в случае SO: заполнено все поля профиля), хотя я знаю обновления SO и назначает значки после определенного количества время. С таким количеством пользователей & значки не могли бы создать проблемы с производительностью (с точки зрения масштаба: большое количество пользователей & значков).

Так структура базы данных я предполагаю, что бы как-то просто, как:

Badges  | Badges_User  | User 
---------------------------------------------- 
bd_id  | bd_id   | user_id 
bd_name | user_id   | etc 
bd_desc | assigned(bool) | 
      | assigned_at  | 

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

Будет ли это еще одна таблица для значков, которые могут быть инкрементальными или просто «прогрессом» в таблице badges_user выше?

Благодарим за внимание и сосредоточим внимание на масштабируемости желаемой системы (например, тысяч пользователей и 20-40 значков).

РЕДАКТИРОВАТЬ: некоторые из нас смутили некоторую путаницу, которую я назначил как дату/время, критерии для награждения значка лучше всего разместить внутри подготовленных запросов/функций для каждого значка, не так ли? (более высокая гибкость)

+0

являются некоторые более популярные значки проверили больше, чем другие, а? – bluedaniel

+3

Не могли бы вы пояснить необходимость «назначенного (bool)»? Разве это не избыток, поскольку у вас не было бы отображения в первом случае, если вам не назначен значок? И почему будет важно количество сообщений на форуме? – Fredrik

+0

первая ошибка! скажем, вы назначали значки в зависимости от количества поставленных должностей, то есть награждали высокие должности хорошими значками -> стимул, чтобы заставить пользователей взаимодействовать. – bluedaniel

ответ

7

Я думаю, что структура, которую вы предложили (без «назначенного» поля в соответствии с комментариями), будет работать с добавлением дополнительной таблицы, например «Submissions_User ", содержащее ссылку на user_id & приращающееся поле для подсчета заявок. Тогда вам понадобится только «прослушиватель событий» в соответствии с this post и будет указано, что вы будете установлены.

РЕДАКТИРОВАТЬ: Для достижения значков запустите прослушиватель событий при каждом представлении (только для пользователя, отправляющего курс), и присудите любой соответствующий значок на месте. Для значков, основанных на времени, я каждую ночь выполнял работу CRON. Проходите через полный список пользователей один раз и награждайте значки, если применимо.

+0

Хорошо, это лучший способ, и как насчет реализации, так как в моем вопросе SO награждает значки по истечении установленного времени, поэтому каждые несколько часов и это тогда [foreach (badge)] -> делать всех пользователей или [foreach (пользователь)] -> делать все значки, это имеет значение? Тогда я мог бы установить значки, которые с меньшей вероятностью будут присуждаться через более длительные промежутки времени? мысли .. и я принимаю в качестве ответа – bluedaniel

7

относительно эскиза, который вы включили: избавиться от булевой колонки на badges_user. здесь нет никакого смысла: это отношение определено в терминах предиката «пользователь user_id заработал значок bd_id at assign_at».

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

4

Я думаю, что это один из тех случаев, когда ваш многозначный стол (Badges_User) подходит.
Но с небольшим изменением, так что неназначенные значки не сохраняются.

Я предполагаю, что assigned_at - это дата и/или время.
По умолчанию, пользователь не имеет значков.

Badges  | Badges_User  | User 
---------------------------------------------- 
bd_id  | bd_id   | user_id 
bd_name | user_id   | etc 
bd_desc | assigned_at  | 
      |      | 

Этот способ хранится только отмеченные значки.
Строка Badges_User создается только тогда, когда пользователь получает значок.

С уважением
        Sigersted

+1

Humm ... Я вижу, что это то же самое, что и da5id. – Sigersted

7

Я хотел бы сохранить подобную структуру типа того, что у вас есть

Badges(badge_id, badge_name, badge_desc) 
Users(user_id, etc) 
UserBadges(badge_id, user_id, date_awarded) 

И затем добавить отслеживания таблицу (ы) в зависимости от того, что вы хотите, чтобы отслеживать и @ какой уровень детализации ... тогда вы можете обновить таблицу соответственно и установить триггеры на нее, чтобы «наградить» значками

User_Activity(user_id, posts, upvotes, downvotes, etc...) 

Вы также можете отслеживать статистику с другой стороны тоже и триггерные бейдж награды

Posts(post_id, user_id, upvotes, downvotes, etc...) 


Некоторые другие хорошие моменты сделаны here

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