Трек еженедельные изменения тенденции a.k.a (дизайн db)

Question

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

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

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

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

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

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

Answer 1

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

T_1, t_2

Тогда А cronjob каждую неделю копии t_1 на T_2 и пересчитывать каждый t_1

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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