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

Наверное, всё же схема "Горячая таблица" без индексов (ну, в разумном понимании слова "без") - "Холодная таблица" со всевозможными индексами и предрассчитанными агрегатами, пополняемая из горячей таблицы в периоды минимальной активности потребителей - наше всё.

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

С другой стороны, если, например, количество транзакций за день - небольшое, ну миллион - 10 миллионов, то, наверное, можно и не париться.
Порезать холодную таблицу по количеству опердней, ну, пусть 365, а в оперативной - держать две секции: До/После времени закрытия опердня.
И по процедуре закрытия опердня формировать из секции "До" горячей таблицы данные для секции, соответствующей конкретному опердню холодной таблицы, уже со всеми индексами, индексированными вью, таблицами предрассчитанных агрегатов, свистелками и перделками.
Понятно, что в отдельную табличку/таблички, рядом с холодной.
А потом одномоментно выносить переключением метаданных секцию "ДО" из горячей таблицы и включать подготовленные данные в холодную.
Причем холодную таблицу - можно и на соседнем сервере держать, проблем то...
Ну, понятно, еще сверххолодная таблица понадобиться, из одних агрегатов за передыдущие годы...

Т.е. это классическая схема "хранилище - оперативные данные", только отказ в обслуживании на момент пополнения хранилища недопустим, а так - никаких чудес.

Всё ИМХО, разумеется.