Разработка системы, основанной на баллах, аналогичной переполнению стека в Ruby on Rails - PullRequest
0 голосов
/ 03 марта 2011

Я не пытаюсь воссоздать переполнение стека, и я смотрел на похожие вопросы, но у них не так много ответов.

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

Например, если бы я проектировал переполнение стека (что опять-таки не так), это бы выглядело примерно так:

  1. Создание вопроса = 5 баллов
  2. Ответ на вопрос = 10 баллов
  3. Выбранный правильный ответ является модификатором x2 в баллах для ответа на вопрос.

С точки зрения дизайна мне кажется, что мне нужны 3 модели для ключевых деталей.

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

Модель points представляет собой справочную таблицу, в которой действия используются для определения своих точек. Он использует тип действий в качестве ключа. Здесь также хранится количество очков для точек и поле для их затухания.

Модификатор - модель, в которой я не уверен, что делать. Я думаю, что это должна быть таблица соответствия, похожая на точки, использующая поле типа действия. Кроме того, он должен быть условным, когда его следует применять. Я не уверен, как сохранить условное утверждение. Также необходимо хранить, как изменяются точки. Например, x2, +5, -10, / 100 и т. Д. Другая проблема заключается в том, как модификатор применяется после того, как действие уже произошло. В моем примере это будет, когда вопрос выбран в качестве ответа. К этому времени очки уже были установлены. Единственный способ, которым я могу думать об этом, - это иметь after_save для каждой модели, которая может быть модификатором, который проверяет таблицу модификаторов и применяет их. Хотя это как-то неправильно для меня.

Есть и другие проблемы, например, как справиться с распадом. Думаю, мне нужна работа cron, которая просто пересчитывает баллы каждого, но кажется, что она плохо масштабируется.

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

Ответы [ 2 ]

0 голосов
/ 01 сентября 2014

Теперь у Rails есть драгоценный камень для достижения этой функции

https://github.com/tute/merit

0 голосов
/ 05 апреля 2013

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

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

...