Sql Server 2008 Nesting Views

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

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

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

Ответы

Ответ 1

Я бы избегал этого любой ценой. Сначала, когда вы просматриваете представления, они не могут быть проиндексированы. Затем, поскольку они должны полностью материализовать основные представления, чтобы перейти на следующий уровень. Таким образом, вы можете материализовать многомиллионные записи, чтобы получить конечный результат из 5 записей. Мы почти потеряли многомиллионного клиента, потому что производительность была настолько ужасающей, когда наши разработчики сделали это в одной базе данных (а не в базе данных, в которой я вносил вклад в разработку).

Наконец, я обнаружил, что эти типы слоев намного сложнее поддерживать, когда вам нужно внести изменения. Это не забавно отслеживать 12 слоев просмотров, чтобы найти тот, который вам нужно исправить. Мы также столкнулись с проблемой, потому что разработчикам было проще просто добавить еще один слой, чем исправить лежащие в основе слои, а затем пытались получить доступ к слишком большому количеству таблиц в одном запросе, и слишком многие из этих таблиц были такими же, как и многомиллионная таблица записей 7 или 8 раз в разных слоях видов.

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

Ответ 2

Другие варианты рассмотрения: Индексированные представления. Может быть опасно использовать, если не использовать правильно, но прирост производительности может быть потрясающим.

Аналитика - такие как группировки наборов

процедуры и временные таблицы. Получите необходимые данные с помощью процедуры, запишите ее в временные таблицы, выберите из временных таблиц.

В целом мне не нравится представление производительности для просмотра в представлении или вложенных представлениях.

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