Здравствуйте, hyp1k, Вы писали:
h> Здравствуйте, wildwind, именно для производительсноти, я правильно понимаю, что нужно добавить кластеризованный индекс и все заработает быстрее?
Затем нужно создать кластерный индекс. При необходимости можно добавить и другие индексы, как и с обычной таблицей. Не забывая про накладные расходы на их поддержку.
h> условно говоря, мне даже запросы переписывать не придется?!
Если у вас Enterprise Edition и представление построено правильно, то да, не придется. Но возможно стоит потратить время, переписать и в дальнейшей разработке обращаться к представлению явно. Это избавит от необходимости каждый раз думать и проверять "а поймет ли SQL Server, что этот запрос можно выполнить через view?". Да и сами запросы станут проще и их поддержка упростится.
В системе есть журналы записей, запись характеризуется набором полей, набор полей записи можно редактировать в системе. Таким образом журналы с данными в системе опираются на классы записей и могут иметь различные структуры. Неудобно то, что отображение журнала — это много джойнов и построение отчетов — это много джойнов. Волнует прежде всего отчетник. Вопрос в том, какие решения есть в mssql (или еще каую-то систему прикрутить), чтобы организовать кэш или кэшируемое представление обновляемое, например, непосредственно перед построением отчета. Или чтобы кэш обновлялся бы при добавлении/обновлении записи. Как это лучше сделать?
Здравствуйте, hyp1k, Вы писали:
h> В системе есть журналы записей, запись характеризуется набором полей, набор полей записи можно редактировать в системе. Таким образом журналы с данными в системе опираются на классы записей и могут иметь различные структуры. Неудобно то, что отображение журнала — это много джойнов и построение отчетов — это много джойнов. Волнует прежде всего отчетник. Вопрос в том, какие решения есть в mssql (или еще каую-то систему прикрутить), чтобы организовать кэш или кэшируемое представление обновляемое, например, непосредственно перед построением отчета. Или чтобы кэш обновлялся бы при добавлении/обновлении записи. Как это лучше сделать?
Общепринятый термин — материализованное представление (materialized view), это для поиска. Реализация в MSSQL называется индексированным представлением (indexed view) и обеспечивает как раз то, что тебе требуется.
Да, если проблема с джойнами заключается только в неудобстве написания запросов, и не затрагивает их производительность, то решением будут просто view, не индексированные.
Здравствуйте, wildwind, именно для производительсноти, я правильно понимаю, что нужно добавить кластеризованный индекс и все заработает быстрее? условно говоря, мне даже запросы переписывать не придется?!
Здравствуйте, hyp1k, Вы писали:
H>В системе есть журналы записей, запись характеризуется набором полей, набор полей записи можно редактировать в системе. Таким образом журналы с данными в системе опираются на классы записей и могут иметь различные структуры. Неудобно то, что отображение журнала — это много джойнов и построение отчетов — это много джойнов. Волнует прежде всего отчетник. Вопрос в том, какие решения есть в mssql (или еще каую-то систему прикрутить), чтобы организовать кэш или кэшируемое представление обновляемое, например, непосредственно перед построением отчета. Или чтобы кэш обновлялся бы при добавлении/обновлении записи. Как это лучше сделать?
По-моему, это не тот путь к оптимизации, по которому нужно идти.
JOIN -- тривиальная операция, и даже если их много (десятки) -- это не проблема.
Главная проблема оптимизации запросов -- эффективная фильтрация нужных данных.