Как спроектировать номера базы данных / атрибутов, чтобы свести к минимуму пересмотр запросов к базе данных?

Question

Я создал обычные модели Match, Team и т. Д., Чтобы создать игру футбольного менеджера, и включил в статистику многие известные статистические данные в качестве атрибутов (общее количество ударов, широких ударов, угловых и т. Д.). Я хотел бы дать статистику для каждого тайма. Поэтому я создал такие атрибуты, как HomeTeamFirstHalfGoals и AwayTeamSecondHalfCorners. Я планирую рассчитать итоги как

HomeTeamTotalGoals = HomeTeamFirstHalfGoals + HomeTeamSecondHalfGoals

в модели соответствия и отображает некоторые или все эти характеристики в виде таблицы LeagueTable по запросу пользователя. Я предполагаю, что пользователь может захотеть увидеть разные таблицы, такие как все матчи, сыгранные за последнюю неделю, или весь матч, включая некоторые вычисляемые атрибуты, такие как TotalGoals и т. Д., Или весь список матчей определенной команды / сезона.

Однако код работает слишком медленно. Я не знаю, связано ли это со средой разработки, и, поскольку у меня мало знаний и больше недоразумений по поводу mysql, мне интересно, как мне составить таблицу соответствий.

Вопрос заключается в том, (поскольку я слышал понятие запроса к базе данных, которое, как я вижу, стоит времени сервера и процессора), следует ли сохранять минимальное количество атрибутов (например, AwayTeamSecondHalfCorners) и вычислять зависимые (например, TotalGoals) на лету или сделать наоборот, чтобы капитальный ремонт на сервере был как минимум?

Примечание. Полагаю, все знают, что создать новый столбец очень просто, набрав A3 = (A1 + A2) в Excel. Меня смущает, насколько это легко в рубиновых представлениях или это более эффективно сделать в таблице mysql? Поскольку у меня нет опыта программирования, приветствуется руководство по простым источникам.

Answer 1

Множество способов подойти к этому.Первым делом нужно начать определять, какие части вашего кода быстры, а какие нет - я бы использовал библиотеку тестов Ruby (http://www.ruby -doc.org / stdlib-1.9.3 / libdoc / benchmark / rdoc /Benchmark.html ).

В общем, я бы рекомендовал хранить все дискретные данные и определять методы для расчета всего, что может быть получено из дискретных данных.Итак, я бы сказал, что общие цели команды были бы примерно такими:

def total_goals
  first_half_goals + second_half_goals
end

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

Одна вещь, которая может привести к большим замедлениям, - это если в вашей базе данных отсутствуют какие-либо индексы - каждый раз, когда у вас есть внешний ключ (обычно любой, который заканчивается на_id; например, если у игры есть away_team_id и home_team_id, то, вероятно, оба являются внешними ключами), в вашей базе данных должен быть соответствующий индекс.Чтобы добавить индекс, создайте новую миграцию базы данных, а затем вставьте некоторый код, подобный следующему:

class AddIndexes < ActiveRecord::Migration

  def self.up
    add_index :games, :home_team_id
    add_index :games, :away_team_id
  end

  def self.down
    remove_index :games, :home_team_id
    remove_index :games, :away_team_id
  end

end

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