В системе есть журналы записей, запись характеризуется набором полей, набор полей записи можно редактировать в системе. Таким образом журналы с данными в системе опираются на классы записей и могут иметь различные структуры. Неудобно то, что отображение журнала — это много джойнов и построение отчетов — это много джойнов. Волнует прежде всего отчетник. Вопрос в том, какие решения есть в mssql (или еще каую-то систему прикрутить), чтобы организовать кэш или кэшируемое представление обновляемое, например, непосредственно перед построением отчета. Или чтобы кэш обновлялся бы при добавлении/обновлении записи. Как это лучше сделать?

Здравствуйте, hyp1k, Вы писали:

h> В системе есть журналы записей, запись характеризуется набором полей, набор полей записи можно редактировать в системе. Таким образом журналы с данными в системе опираются на классы записей и могут иметь различные структуры. Неудобно то, что отображение журнала — это много джойнов и построение отчетов — это много джойнов. Волнует прежде всего отчетник. Вопрос в том, какие решения есть в mssql (или еще каую-то систему прикрутить), чтобы организовать кэш или кэшируемое представление обновляемое, например, непосредственно перед построением отчета. Или чтобы кэш обновлялся бы при добавлении/обновлении записи. Как это лучше сделать?

Общепринятый термин — материализованное представление (materialized view), это для поиска. Реализация в MSSQL называется индексированным представлением (indexed view) и обеспечивает как раз то, что тебе требуется.

Здравствуйте, wildwind, Вы писали:

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

P.S. Прошу прощения за оверквотинг.

Здравствуйте, wildwind, именно для производительсноти, я правильно понимаю, что нужно добавить кластеризованный индекс и все заработает быстрее? условно говоря, мне даже запросы переписывать не придется?!

Здравствуйте, hyp1k, Вы писали:

h> Здравствуйте, wildwind, именно для производительсноти, я правильно понимаю, что нужно добавить кластеризованный индекс и все заработает быстрее?

Для начала нужно создать само представление, если его еще нет. Это самый важный этап, нужно учесть разные ограничения, и составить текст представления так, чтобы эффект от него был максимальным. См.:
https://technet.microsoft.com/en-us/library/ms187864%28v=sql.105%29.aspx
https://technet.microsoft.com/en-us/library/dd171921%28v=sql.100%29.aspx
https://msdn.microsoft.com/en-us/library/ms191432.aspx#Restrictions

Затем нужно создать кластерный индекс. При необходимости можно добавить и другие индексы, как и с обычной таблицей. Не забывая про накладные расходы на их поддержку.

h> условно говоря, мне даже запросы переписывать не придется?!

Если у вас Enterprise Edition и представление построено правильно, то да, не придется. Но возможно стоит потратить время, переписать и в дальнейшей разработке обращаться к представлению явно. Это избавит от необходимости каждый раз думать и проверять "а поймет ли SQL Server, что этот запрос можно выполнить через view?". Да и сами запросы станут проще и их поддержка упростится.

Здравствуйте, hyp1k, Вы писали:

H>В системе есть журналы записей, запись характеризуется набором полей, набор полей записи можно редактировать в системе. Таким образом журналы с данными в системе опираются на классы записей и могут иметь различные структуры. Неудобно то, что отображение журнала — это много джойнов и построение отчетов — это много джойнов. Волнует прежде всего отчетник. Вопрос в том, какие решения есть в mssql (или еще каую-то систему прикрутить), чтобы организовать кэш или кэшируемое представление обновляемое, например, непосредственно перед построением отчета. Или чтобы кэш обновлялся бы при добавлении/обновлении записи. Как это лучше сделать?

По-моему, это не тот путь к оптимизации, по которому нужно идти.
JOIN -- тривиальная операция, и даже если их много (десятки) -- это не проблема.
Главная проблема оптимизации запросов -- эффективная фильтрация нужных данных.