Представления или табличные функции или что-то еще - PullRequest
2 голосов
/ 22 декабря 2009

Я разработал 5 хранимых процедур, которые почти используют одно и то же условие соединения, но параметры или значения, в которых предложение where меняется для каждого из них при разных запусках. Это лучшее решение для создания представления со всеми условиями соединения без предложения where, а затем запрос из представления или работа в представлении? Можно ли автоматически обновлять представления, если я создаю представление? Могу ли я выполнять подзапросы или запросы, аналогичные (я думаю, что читаю где-то представления, не поддерживающие подзапросы, но не уверен на 100%)

select count(x1) as x1cnt, count(x2) as x2count
from (
        select x1,x2, 
        (
        case when x1 is 'y' then 1 else 0 end +
        case when x2 is 'y' then 1 else 0 end
        ) per
        from vw_viewname) v1
where v1.per = 1

Обновлено ниже:

In my queries i use joins similar to this also

select c1,c2,c3
FROM [[join conditions - 5 tables]]
Inner join
(
select x1,x2,x3, some case statements
FROM [[join conditions - 5 tables]]
where t1.s1 = val1 and t2.s2 = v2 etc
) s
on s.id = id

поэтому я использую соединение дважды, поэтому я подумал, можно ли уменьшить его, используя некоторые представления

Ответы [ 7 ]

2 голосов
/ 22 декабря 2009

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

Вы получите таблицу результатов общего вида для работы. В основном View запускает запрос, когда вы его используете, так что вы получите результаты, как если бы вы выполняли запрос самостоятельно каким-то другим механизмом. Вы можете выполнять подзапросы для представления так же, как если бы это была другая таблица. Это не должно быть проблемой. Но если у вас есть 5 различных запросов, выполняющих 5 конкретных задач, то, вероятно, полезно оставить это так. Один или два из них могут быть вызваны больше, и вы будете торговать их производительностью с помощью таблицы общего вида и ничего не получите за это, кроме повторного использования представления.

Я бы только построил представление, если бы у вас была определенная выгода от этого.

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

РЕДАКТИРОВАТЬ: Ну, я думаю, это только ухудшило бы. Вы бы просто вызывали представление дважды, и если это универсальное представление, это означает, что при каждом из этих вызовов будет получено много общих результатов.

Я бы сказал, просто сконцентрируйтесь на оптимизации этих запросов, чтобы получить именно то, что вам нужно. Это действительно то, что у вас есть 5 различных процедур в любом случае, верно? :)

1 голос
/ 22 декабря 2009

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

На твоем месте я бы оставил все как есть. Может показаться, что вы должны сжать свой код (каждый из 5 скриптов имеет почти одинаковый код), но здесь важно то, что отличается.

1 голос
/ 22 декабря 2009

Это 5 разных запросов, поэтому оставьте это так.

Соблазнительно инкапсулировать похожие СОЕДИНЕНИЯ в представление, но прежде чем вы это узнаете, у вас есть представления поверх просмотров и ужасная производительность. Я видел это много раз.

«Подзапрос в представлении», вероятно, относится к индексированным представлениям, которые имеют ограничения.

0 голосов
/ 23 декабря 2009

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

http://msmvps.com/blogs/robfarley/archive/2008/11/09/join-simplification-in-sql-server.aspx

Хранимые процедуры будут выполнять одну и ту же работу каждый раз (параметры имеют некоторый эффект), но представление (или встроенный TVF) будет расширено во внешний запрос и упрощено.

0 голосов
/ 22 декабря 2009

Хорошо создать представление, даже если оно содержит подвыбор. Вы можете удалить, где для представления.

Вы уверены, что хотите использовать COUNT без группы? Подсчитывает количество строк, которые содержат ненулевые значения или параметр.

0 голосов
/ 22 декабря 2009

Представления SQL Server поддерживают подзапросы. И, в некотором смысле, представления автоматически обновляются, потому что представление не является постоянным объектом (если вы не используете индексированное представление). С неиндексированным представлением каждый раз, когда вы запрашиваете представление, оно использует базовые таблицы. Таким образом, ваше представление будет таким же актуальным, как и таблицы, на которых они основаны.

Мне кажется, что вид будет хорошим выбором здесь.

0 голосов
/ 22 декабря 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...