Я бы выбрал представление (как предлагали другие) или встроенную табличную функцию (преимущества этого в том, что вам нужны параметры - например, диапазон дат или учетная запись клиента), которые могут помочь пользователям не запрашивать запросы без любые ограничения на проблемное пространство) в первую очередь. Встроенный TVF на самом деле является параметризованным представлением и гораздо ближе к представлению с точки зрения того, как механизм обрабатывает их, чем к табличной функции с несколькими утверждениями или скалярной функции, которая может выполнять невероятно плохо.
Однако в некоторых случаях это может повлиять на производительность производства, если представление является сложным или интенсивным. С плохо написанными специальными пользовательскими запросами, это также может привести к тому, что блокировки будут сохраняться дольше или увеличиваться дальше, чем они были бы в лучше построенном запросе. Пользователи также могут неверно истолковать модель данных E-R и получить умноженные числа в случаях, когда существуют отношения «многие к одному» или «многие ко многим». Следующим вариантом может быть материализация этих представлений с помощью индексов или создание таблиц и их обновление, что приближает нас к моему следующему варианту ...
Итак, учитывая эти недостатки опции просмотра и уже подумывая о том, чтобы смягчить ее, начав создавать копии данных, я бы рассмотрел следующий вариант - иметь отдельную версию данных, предназначенную только для чтения (для этих пользователей), которая структурирован по-разному. Обычно я сначала смотрю на звездную схему в стиле Кимбалла. Вам не нужно иметь полноценное, согласованное по времени хранилище данных. Конечно, это вариант, но вы можете просто поддерживать модель отчетности в актуальном состоянии с данными. Звездные схемы являются особой формой денормализации и особенно хороши для числовых отчетов, и пользователи не должны злоупотреблять данной звездой. Вы можете поддерживать звезду в актуальном состоянии несколькими способами, в том числе триггерами, запланированными заданиями и т. Д. Они могут быть очень быстрыми для составления отчетов и запускаться в одной и той же производственной установке - возможно, в отдельном экземпляре, а не просто в отдельной базе данных.
Хотя такое решение может потребовать от вас более чем удвоения требований к хранилищу, по сравнению с другими практиками это может быть действительно хорошим вариантом, если вы хорошо понимаете свои данные и не против иметь две модели - одну для транзакций и один для анализа (обратите внимание, что вы уже начнете иметь это логическое разделение в любом случае с использованием самого простого первого варианта представления).
Некоторые архитекторы часто удваивают свои серверы и используют ту же модель с той же репликацией для предоставления сервера отчетов, который индексируется более интенсивно или по-разному. Такой второй сервер не влияет на производственные транзакции с требованиями к отчетности и может быть достаточно легко обновлен. Будет только одна модель, но, конечно, у нее есть те же проблемы с юзабилити, когда пользователям предоставляется специальный доступ только к базовой модели без ущерба для производительности, поскольку они получают собственную игровую площадку.
Есть много способов снять шкуру с этих кошек. Удачи.