Представления базы данных влияют на производительность запросов?
На самом деле вы хотите ID с, для которых не существует распределены вегетарианские или фруктовые.
Таким образом, вы используете NOT EXISTS и в подзапросе вы рассматриваете только записи в категориях с date_distributed is NOT null
select *
from t1
where NOT exists (select null
from t2
where t2.t1id = t1.id and
t2.category in ('Veggie','Fruits') and
t2.date_distributed is NOT null
);
ID
----------
2
3
4
6
7
5 ответов
Хотя определенное выполнение запроса в представлении и том же запросе, работающем за пределами представления, должно работать эквивалентно, вещи становятся намного более сложными быстро, когда необходимо присоединиться к двум представлениям вместе. Можно легко закончить тем, что принесли таблицы, в которых Вы не нуждаетесь в запрос или введение таблиц избыточно. Оптимизатор базы данных может испытать больше затруднений при создании хорошего плана выполнения запросов. Таким образом, в то время как представления могут быть очень хорошими с точки зрения разрешения более мелкомодульной безопасности и т.п., они не обязательно хороши для модульного принципа.
Это зависит от RDBMS, но обычно нет продолжения оптимизации, и это - просто удобный способ упростить запросы. Некоторые системы баз данных используют "осуществленные представления" однако, которые действительно используют механизм кэширования.
Обычно представление является просто способом создать общее сокращение от определения наборов результатов, в которых Вы часто нуждаетесь.
Однако существует оборотная сторона. Искушение состоит в том, чтобы добавить в каждом столбце, Вы думаете, что Вам, возможно, понадобилось бы где-нибудь когда-то, когда Вы хотели бы использовать представление. Таким образом, YAGNI нарушен. Не только столбцы, но и иногда дополнительные внешние объединения прикрепляются на "на всякий случай". Так покрытие индексов не могло бы больше покрывать, и план запросов может увеличиться в сложности (и заглядывать эффективности).
YAGNI является критическим понятием в дизайне SQL.
Я всегда полагал, что Представления похожи на Хранимые процедуры только для чтения. Вы даете базе данных столько информации, сколько Вы можете заранее, таким образом, она может предварительно скомпилировать как лучше всего, она может.
Можно индексировать представления, также разрешающие Вам доступ к оптимизированному представлению данных, которые Вы, после для типа запроса Вы работаете.
Вообще говоря, представления должны работать эквивалентно к запросу, записанному непосредственно на базовых таблицах.
Но: могут быть пограничные случаи, и Вам надлежало бы тестировать свой код. Все современные системы RDBMS имеют инструменты, которые позволят Вам видеть queryplans и выполнение монитора. Не берите мой (или ничей больше) слово для него, когда у Вас смогут быть категорические данные под рукой.