Лучший способ сохранить критерии значка?

Я думал о том, как реализовать функцию значка, аналогичную SO, на новом веб-сайте. Как лучше всего хранить критерии для значков?

Две идеи:

  • Весь код
  • «Вторая система» - создать мета-архитектуру для определения значков и их критериев. Сохраните некоторую информацию в базе данных и запросите код, чтобы выяснить значки и их критерии.

Есть ли способы лучше?


person Ryan Doherty    schedule 07.02.2009    source источник


Ответы (2)


Правила.

Вы создаете события в системе и используете правила в процессоре потока событий.

В частности, скажем, у вас есть значок «Сделано 10 сообщений». Вы не запускаете "select count (*) from posts where user =: user" для каждого сообщения. Скорее, у вас есть простое правило, которое отслеживает каждую приходящую публикацию и «считает их», сохраняя состояние правил в профиле пользователя.

Таким образом, «сделал 10 постов» так же дешево, как «сделал 1 000 000 постов».

Это также делает систему более расширяемой.

person Will Hartung    schedule 07.02.2009
comment
Если вы идете по этому пути, будьте осторожны в случаях, когда вы добавляете новый значок, и вам нужно проанализировать, какие существующие пользователи уже должны были его заработать. - person Doug McClean; 07.02.2009
comment
Да, это абсолютно обратная сторона системы, но все же она более гибкая и масштабируемая, поскольку (обычно) добавление новых значков происходит гораздо реже, чем их тестирование и их присуждение. - person Will Hartung; 07.02.2009
comment
Итак, как бы вы справились с добавлением значков в будущем? Допустим, у меня есть новый значок, такой как значок Woot, который добавил SO. Как бы вы сделали это задним числом? - person Micah; 24.06.2009
comment
Вам понадобится какой-то механизм для повторного запуска данных истории событий, чтобы собрать статистику, необходимую для вашего нового значка, и обновить ее. - person Will Hartung; 25.06.2009
comment
Заполнение значков - главный недостаток этого подхода. В основном ответ заключается в том, что вам все равно нужно написать задание cron (вероятно, чистый SQL), которое содержит логику / критерии правила - так почему бы просто не написать cron для начала и пропустить (по общему признанию, более привлекательный) процессор потока событий? - person MikeMurko; 25.10.2012
comment
@MikeMurko: Все зависит от того, насколько отзывчивым вы хотите, чтобы ваши значки были объявлены, насколько велики ваши наборы данных и т. Д. - person Will Hartung; 25.10.2012
comment
Согласовано. Подход, основанный на работе, не такой отзывчивый. Я больше говорил о необходимости работы при заполнении старых данных (т.е. когда вы создаете новый значок или впервые внедряете эту систему на существующий продукт). Я думаю, вы могли бы моделировать события (последовательно) и запускать их через ESP ... но это легче сказать, чем сделать. - person MikeMurko; 25.10.2012

Я согласен с Уиллом в этом вопросе.

Создавайте «события» на страницах, чтобы каждый раз, когда событие происходило, т.е. пользователь удаляет сообщение, он будет запрашивать модуль события с событием, скажем, EVENT_USER_DELETE_POST, а затем вы можете выбрать это событие и построить запрос на его основе. Затем вы можете решить, присуждается ли значок или нет.

Это позволит разделить две логики и сохранить модульную конструкцию. Это должно быть очень легко реализовать.

Единственным недостатком является то, что если событие не было «захвачено», то пользователь вполне мог заработать критерий значка, но он еще не был вознагражден. Однако этого никогда не должно происходить. Единственная ситуация, о которой я могу думать, - это когда база данных манипулируется вручную.

person Gary Green    schedule 07.02.2009