У нас есть таблица платежей, и агенты получают комиссию за платежи. Комиссия основывается на нескольких различных факторах, например, на том, сколько времени потребовалось для получения платежа, поэтому при вычислении размера комиссии, которую получает агент, требуются некоторые расчеты, но ничего сложного.
Например, это, вероятно, никогда не будет более сложным, чем это:
SELECT Payments.Amount * CASE
WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 1 THEN Rates.Rate1
WHEN DateDiff(year, Client.Received, Payments.DatePaid) = 2 THEN Rates.Rate2
ELSE Rates.Rate3 ENDИмеет ли смысл строить 2-ю таблицу для хранения этих данных, а не запрашивать ее в любое время, когда это необходимо? Или я должен просто придерживаться запросов времени выполнения, которые извлекают данные всякий раз, когда они запрашиваются?
И что более важно, какие факторы следует использовать при определении того, должен ли запрос выполняться в любое время, когда необходимы данные, или данные должны храниться в отдельной таблице?
Ответы:
Если запрос выполняется довольно редко (например, отчет), то построение таблицы на лету, вероятно, лучше 1 . Если запрос выполняется часто, а временная таблица требуется для производительности, у вас, возможно, есть проблема.
Если таблица дешевая, то делайте это как временную таблицу. Пока база данных достаточно быстрая, вам это может сойти с рук. Однако вам нужно следить за производительностью.
Если таблица не должна быть полностью обновленной, но будет являться предметом относительно частых отчетов, тогда, вероятно, лучшим вариантом будет периодическое восстановление.
Если создание таблицы требует больших затрат, но ее необходимо обновлять, возможно, вам потребуется управлять ею как денормализованной структурой, которая поддерживается как индексированное представление или с помощью триггеров. Это несколько сложнее и накладывает дополнительное бремя на операции записи.
В более экстремальных случаях (например, большие объемы данных) вам может понадобиться гибридный подход, при котором исторические данные запрашиваются из денормализованной структуры, оптимизированной для производительности, а текущие данные запрашиваются из действующего приложения.
В самых экстремальных случаях это может привести к появлению каналов витрин данных с малой задержкой и гибридных решений OLAP, поэтому это наиболее сложный процесс с точки зрения глубины залегания кроличьей норы. Лучше избегать этого, если у вас нет настоящих требований.
В случае, который вы описали выше, периодическая перестройка таблицы отчетности звучит уместно. Если вам нужно закрыть в середине дня для запуска отчетов, то вы можете предоставить средство для принудительного обновления из приложения. В противном случае запустите его в одночасье, и агенты увидят комиссию «как в полночь предыдущего рабочего дня».
1
select intoзапрос создания временных таблиц на SQL Server выполняется довольно быстро, поскольку операции вставки минимально регистрируются.Итак, для подведения итогов вы используете следующие факторы, чтобы определить, должна ли у вас быть новая таблица для ваших данных или нет:
источник
how often the data is neededиhow expensive the query is?Одной из проблем, не охваченных в принятом ответе, является «нужно ли вам это значение с течением времени» и «возможно ли изменится формула».
Например, рассмотрим пример комиссии. Если комиссия выплачена, сумма должна быть сохранена, поскольку это историческая цифра того, что было фактически уплачено. Способ расчета комиссионных может измениться в следующем месяце (и часто так), но это не изменит того, что было фактически оплачено, и которое должно храниться отдельно.
Это та же идея, что и сохранение цены, которую клиент фактически заплатил за продукт (после расчета скидок и т. Д.), Вместо того, чтобы полагаться на формулу с таблицей цен для выполнения каких-либо действий, кроме первоначального расчета, поскольку цена продукта в следующем месяце может не быть такой же, какой была цена, когда заказчик сделал заказ.
Если вам нужна историческая запись о том, какое значение было в определенный момент времени, всегда сохраняйте это значение после использования формулы для начального расчета.
источник
Вероятно, не представляет интереса, если вы заблокированы в конкретной базе данных, но MariaDB (основанная на MySQL рабочая) имеет нечто замечательное, называемое «виртуальными столбцами», которое можно вычислять на лету или кэшировать в реальном хранилище, но автоматически пересчитывается по мере необходимости. Я пропустил эту функцию, так как много лет назад я покинул FileMaker Pro для мира SQL ...
источник