Отслеживание еженедельных изменений a.k.a трендов (дизайн БД)

Question

У меня есть сайт, где люди могут добавлять свои любимые телешоу.
Я хотел бы иметь некоторые тенденции статистики. Пример:

1. (1 без изменений) Теория большого взрыва
2. (3-ий на прошлой неделе) Как я встретил вашу маму
3. (2-ая последняя неделя) Дом
4. (30-е место на прошлой неделе, рост на 400%) Никита

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

1. Один раз в неделю я бегу cronjob.
2. Кронджоб рассчитывает текущую позицию каждого шоу.
3. Позиция последних недель копируется в другой столбец БД.
4. Из этих двух значений (столбцов) я могу рассчитать изменение.

Хорошо ли подходит этот подход? Как бы вы это сделали? :)

PS. Я - программист Rails, но это не должно иметь значения, если только некоторые плагины не созданы для аналогичной цели.

Answer 1

Таблица MovieVotes отслеживает голоса за каждый день.Таблица MovieRating представляет собой периодический (еженедельный) снимок.

Одна строка в таблице Calendar - это один день.

CalendarId в таблице MovieRating указывает на последний день рейтингового периода, в данном случае WHERE DayInWeek = 7.

CalendarId в таблице MovieVotes указывает на текущий день.

Из MovieRating можно просматривать еженедельные рейтинги и голоса.С MovieVotes вы можете агрегировать голоса за произвольный период.

Answer 2

Используя модель Дамира в качестве примера. Я бы изменил порядок MovieID и CalID ... вы захотите запросить другой CalendarID для одного и того же хода больше, чем наоборот.

Его таблица MovieVotes уже агрегирована по дням. Добавление 7 значений вместе для итоговых значений за последние недели НЕ является проблемой для базы данных и делает таблицу MovieRating как агрегирование ненужным. Если бы у MovieVotes был столбец datetime для хранения точного времени каждого голосования, тогда было бы необходимо использовать MovieRating в качестве ежедневной агрегации ... нет необходимости просматривать тысячи записей каждый раз, когда вам нужно показать общее количество. Вот где сияет преагрегирующий.

Теперь, если вы кластеризуете данные на этом ПК MovieID, DateID у вас золотой. Чтобы вычислить любой диапазон дат для любого фильма, ваша БД будет обходить b-дерево, чтобы добраться до этого идентификатора фильма, а затем обойти оставшуюся часть дерева, чтобы добраться до начальной даты, теперь вы находитесь в листовом блоке с первой датой и есть все шансы, что ВСЕ ваши даты в любом случае находятся в этом блоке. Таким образом, вы будете знать, что ввод-вывод сложен для суммирования за 7 дней, просто немного больше ЦП для чтения строк из блока, а затем суммирования значений.

Answer 3

Вы можете добавить два индекса в таблицу данных:

t_1, t_2

Затем cronjob каждую неделю копирует t_1 в t_2 и пересчитывает каждый t_1

я нахожу егоэффективен, потому что вы «платите» только за 2 индекса в таблице данных, но вам не понадобится объединение при чтении данных.