Я просматривал этот сайт для ответа, но я все еще немного не уверен, как планировать подобную систему в ее структуре и реализации базы данных.
В PHP и MySQL было бы ясно, что некоторые достижения заработаны немедленно (когда в случае SO с особыми действиями): заполнено все поля профиля), хотя я знаю обновления SO и назначает значки через определенное время. С таким количеством пользователей и значков это не создаст проблем с производительностью (с точки зрения масштаба: большое количество пользователей и значков).
Таким образом, структура базы данных, которую я предполагаю, будет такой простой, как:
Badges | Badges_User | User ---------------------------------------------- bd_id | bd_id | user_id bd_name | user_id | etc bd_desc | assigned(bool) | | assigned_at | Но, как утверждают некоторые люди, было бы лучше иметь инкрементный подход, так что пользователь, у которого есть 1 000 000 сообщений на форуме, не замедлит выполнение каких-либо функций.
Будет ли это еще одна таблица для значков, которые могут быть инкрементальными или просто «прогрессом» в таблице badges_user выше?
Благодарим за чтение и сосредоточим внимание на масштабируемости желаемой системы (например, тысячи пользователей и 20-40 значков).
РЕДАКТИРОВАТЬ: чтобы кто-то смутил некоторую путаницу, которую я назначил в качестве даты / времени, критерии для награждения значка лучше всего разместить внутри подготовленных запросов / функций для каждого значка, не так ли? (более высокая гибкость)
Я думаю, что структура, которую вы предложили (без «назначенного» поля в соответствии с комментариями), будет работать с добавлением дополнительной таблицы, например, «Submissions_User», содержащей ссылку на user_id и поле увеличения для подсчета представлений. Тогда все, что вам нужно, это «прослушиватель событий» в соответствии с этим сообщением, и вы должны указать, что вы будете установлены.
EDIT: для значков достижений запустите прослушиватель событий при каждом представлении (только для пользователя, отправляющего курс), и назначьте соответствующий значок на месте. Для значков, основанных на времени, я каждую ночь выполнял работу CRON. Проходите через полный список пользователей один раз и награждайте значки, если применимо.
в отношении эскиза, который вы включили: избавиться от булевого столбца на badges_user. здесь нет никакого смысла: это отношение определено в терминах предиката «пользователь user_id заработал значок bd_id at assign_at».
как для вашего общего вопроса: определите схему, которая будет относительной, независимо от скорости в первую очередь (это избавит вас от половины потенциальных проблем с перфомансом, возможно, в обмен на различные перфомансы), проиндексируйте ее правильно (что правильно зависит от шаблоны запросов), то, если он медленный, выведите (все еще реляционный) дизайн из этого быстрее. например, вам может потребоваться предварительное вычисление агрегатов и т. д.
Я бы сохранил аналогичную структуру с тем, что у вас есть
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...)
Я думаю, что это один из тех случаев, когда ваша таблица «многие-ко-многим» (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