Я думал о том, как реализовать функцию значка, подобную SO на новом веб-сайте. Каков наилучший способ хранения критериев для значков?Лучший способ хранения критериев для значков?
Две идеи:
Есть ли лучшие способы?
Правила.
Вы создаете события в системе и используете правила в процессоре потока событий.
В частности, скажем, у вас есть значок «made 10 posts». Вы не запускаете «select count (*) из сообщений, где user =: user» для каждого сообщения. Скорее, у вас есть простое правило, которое следит за каждым сообщением и «подсчитывает», сохраняя правила в профиле пользователя.
Таким образом, «сделано 10 сообщений» столь же дешево, как и «сделанные 1 000 000» сообщений.
Это также делает систему гораздо более расширяемой.
Я согласен с Волей на этом.
Создайте «события» над страницами, чтобы каждый раз, когда происходит событие, т.е. пользователь удаляет сообщение, он будет запрашивать модуль события с событием, скажем, EVENT_USER_DELETE_POST, а затем вы можете выбрать это событие и построить на нем запрос. Затем вы можете решить, удостоен ли значок или нет.
Это позволит сохранить две логики отдельно и сохранить модульный дизайн. Это должно быть очень легко реализовать таким образом.
Единственным недостатком является то, что если событие не было «захвачено», то пользователь, возможно, заслужил критерии пропуска, но он еще не был вознагражден. Однако этого никогда не должно происходить. Единственная ситуация, о которой я могу думать, - это манипулировать базой данных вручную.
Если вы идете по этому маршруту, будьте внимательны к случаям, когда вы добавляете новый значок, и вам нужно проанализировать, что уже должны были занять уже существующие пользователи. –
Да, абсолютно недостаток системы, но все же ее более гибкий и масштабируемый, поскольку (как правило) добавление новых значков происходит гораздо меньше, чем тестирование и присуждение. –
Итак, как бы вы справлялись с добавлением значков по дороге? Скажем, у меня есть новый значок, как значок «woot», который добавлен SO. Как бы вы сделали это ретроактивным? – Micah