SQL Server: Движок будет выполнять вещи из представления, которые не нужны?

Question

Если у меня есть представление, которое генерирует несколько столбцов:

CREATE VIEW dbo.foo AS
SELECT 
    id,
    SUM(SELECT [...] ) AS c1,
    STDEV(SELECT [...] ) AS c2,
    AVG(SELECT [...] ) AS c3,
    MIN(SELECT [...] ) AS c4,
    MAX(SELECT [...] ) AS c5,
    SUM(SELECT [...] ) AS c6,
    [...]
    COUNT(SELECT [...] ) AS cN,
FROM Table
GROUP BY id

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

SELECT id, c382
FROM foo
WHERE id = 42

Будет ли SQL Server вычислять все столбцызначения, только чтобы игнорировать их?

По моему опыту, ответ, кажется, "да".Запрос:

SELECT id, c382
FROM foo
WHERE id = 42

будет медленнее, чем я думаю.Если я нарушу абстракцию, дублируя нужный мне код:

SELECT id, c382
FROM (
      SELECT 
       id,
       MAX(SELECT [...] ) AS c382
   FROM Table
   GROUP BY id
) AS MiniView
WHERE id = 42

Запрос выполняется лучше.

Или, возможно, в более реальных конструкциях он начинает разваливаться:

SELECT bar.*, foo.384
FROM bar
    INNER JOIN foo
    ON bar.Bing = foo.id
WHERE bar.Reticulated = 'splines'

Я сумасшедший или SQL Server (2000) сумасшедший?

Answer 1

Обычно это работает в SQL Server 2000. Это также в значительной степени исправлено в SQL Server 2005 и более поздних версиях.

Answer 2

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

К сожалению, это способ взглядов.

Однако вы можете отказаться от создания в столбце такого количества столбцов, которые не будут использоваться?

Answer 3

Я не понимаю последнюю часть вашего вопроса, но первая часть является верным утверждением и подводит итог проблемы с представлениями.

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

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

Большую часть времени вы можете сделать намного лучше с помощью хранимой процедуры IMO.

Answer 4

Вы можете создать материализованное представление (которое индексируется и повышает производительность, но учтите, что вы не можете сделать это для представления, которое вызывает представление (и если вы считаете, что производительность сейчас плохая, подождите, пока вы не попробуете это) .

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