2011-12-16 1 views
3

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

Например, если у меня есть 5 столбцов в моей таблице, и мое представление содержит те же самые 5 столбцов, но также 10 простых вычисляемых столбцов и 10 дорогих вычисляемых столбцов (с использованием средних или подобных) и решили выбрать только один или два простых вычисляемых столбцов, я ожидал бы, что это будет более дорогостоящим, чем если бы я разделил дорогие столбцы на их собственное представление?

Редактировать:
Меня особенно интересуют ответы на вопросы, касающиеся баз данных SQL Server и Postgres, но при необходимости будет более общий ответ.

Edit2:
Я смотрел на планы запросов в SQL Server и это, кажется, не потрудились сделать план для вычисляемых столбцов, когда они не выбраны, так что я надеюсь, что это прекрасно, чтобы объединить все столбцы на один вид, но хотел бы подтвердить: D

Редактировать 3:
@NaveenBabu У меня пока нет проблем с производительностью - это несколько гипотетически. Дополнительные столбцы будут в основном такими вещами, как: DATEPART(mm, aDateField), DATEPART(dd, aDateField) т.е. простые дешевые расширения к столу. Но будет более сложные дорогие колонки, как: (SELECT COUNT(*) FROM events WHERE events.iTicket = tickets.iCode) as NumberOfEvents

Так что я думаю, если вы хотите общий пример мнение будет:

CREATE VIEW TicketsView AS 
SELECT 
    tickets.idx, tickets.a, tickets.b, tickets.c, tickets.d, 
    DATEPART(mm, a) as ticketMonth, DATEPART(dd, a) as ticketDay, 
    DATEPART(yy, a) as ticketYear, 
    (SELECT COUNT(*) FROM events WHERE events.iTicket = tickets.idx) as numEvents 
FROM tickets 

Или что-то подобное. Последний столбец явно дороже, чем остальные: Если мне SELECT tickets.idx, tickets.b, tickets.ticketMonth FROM TicketsView, вам нужно сделать подзапрос/счетчик для вычисления numEvents, так как я не выбрал его из представления?

+0

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

+0

Это действительно зависит от вашего вида. Есть много случаев, когда оптимизатору не будет выбора, кроме как включать даже те столбцы, которые вы не выбираете. – ivan

+0

@NaveenBabu Отредактировал мой вопрос с ответами ... –

ответ

2

В SQL Server основной принцип заключается в том, что представления расширяются в строке.

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

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

Если для получения этого столбца требуется объединение, соединение по-прежнему необходимо - оно может дублировать или фильтровать строки из другой таблицы и т. Д. Но скалярные вычисления, скорее всего, не произойдут.

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

 Смежные вопросы

  • Нет связанных вопросов^_^