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

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

Например, это, вероятно, никогда не будет более сложным, чем это:

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-ю таблицу для хранения этих данных, а не запрашивать ее в любое время, когда это необходимо? Или я должен просто придерживаться запросов времени выполнения, которые извлекают данные всякий раз, когда они запрашиваются?

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

sql-server sql-server-2005 query-performance

— Рейчел
источник

Один из ключевых вопросов: «Как часто люди хотят запрашивать эти данные?» Это отчет или экран с интенсивным движением в приложении?

— ConcernedOfTunbridgeWells

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

— Рейчел

Вероятно, лучше всего встроить его в таблицу отчетности по ночному процессу, и комиссия «по состоянию на прошлую ночь». Если у вас есть закрытый процесс, в котором вам необходимо закрыть отчет, тогда вы можете предоставить в приложении средство для принудительного восстановления.

— ConcernedOfTunbridgeWells

По моему опыту, даты «AsOf» довольно часто встречаются в подобных операциях в финансовом контексте. Таким образом, таблица (как отмечает @ConcernedOfTunbridgeWells) с такой датой «AsOf» должна быть вполне приемлемой.

— swasheck

Соответствующий пост: dba.stackexchange.com/q/7592/2660

— Ник Чаммас,

Ответы:

Если запрос выполняется довольно редко (например, отчет), то построение таблицы на лету, вероятно, лучше ¹ . Если запрос выполняется часто, а временная таблица требуется для производительности, у вас, возможно, есть проблема.

Если таблица дешевая, то делайте это как временную таблицу. Пока база данных достаточно быстрая, вам это может сойти с рук. Однако вам нужно следить за производительностью.
Если таблица не должна быть полностью обновленной, но будет являться предметом относительно частых отчетов, тогда, вероятно, лучшим вариантом будет периодическое восстановление.
Если создание таблицы требует больших затрат, но ее необходимо обновлять, возможно, вам потребуется управлять ею как денормализованной структурой, которая поддерживается как индексированное представление или с помощью триггеров. Это несколько сложнее и накладывает дополнительное бремя на операции записи.

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

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

В случае, который вы описали выше, периодическая перестройка таблицы отчетности звучит уместно. Если вам нужно закрыть в середине дня для запуска отчетов, то вы можете предоставить средство для принудительного обновления из приложения. В противном случае запустите его в одночасье, и агенты увидят комиссию «как в полночь предыдущего рабочего дня».

¹ select into запрос создания временных таблиц на SQL Server выполняется довольно быстро, поскольку операции вставки минимально регистрируются.

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

Как часто нужны данные
Как дорого получить данные
Насколько актуальными должны быть данные

— ConcernedOfTunbridgeWells
источник

Таким образом, в основном единственные два фактора, которые вы используете при определении, нужна ли вам постоянная таблица для данных вместо того, чтобы запрашивать ее при необходимости, how often the data is neededи how expensive the query is?

— Рэйчел

@Rachel - Кроме того, "насколько актуальными должны быть данные?"

— ConcernedOfTunbridgeWells

Одной из проблем, не охваченных в принятом ответе, является «нужно ли вам это значение с течением времени» и «возможно ли изменится формула».

Например, рассмотрим пример комиссии. Если комиссия выплачена, сумма должна быть сохранена, поскольку это историческая цифра того, что было фактически уплачено. Способ расчета комиссионных может измениться в следующем месяце (и часто так), но это не изменит того, что было фактически оплачено, и которое должно храниться отдельно.

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

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

— HLGEM
источник

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

— Рейчел

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

— PSR

Вероятно, не представляет интереса, если вы заблокированы в конкретной базе данных, но MariaDB (основанная на MySQL рабочая) имеет нечто замечательное, называемое «виртуальными столбцами», которое можно вычислять на лету или кэшировать в реальном хранилище, но автоматически пересчитывается по мере необходимости. Я пропустил эту функцию, так как много лет назад я покинул FileMaker Pro для мира SQL ...

— Ян Стейнман
источник