Является ли просмотр быстрее, чем естественное объединение в Oracle?как насчет postgresql? - PullRequest
2 голосов
/ 21 января 2011
SELECT cec.*
  FROM mam.category cec


SELECT cec.year, ces.*
  FROM mam.subcategory ces
  JOIN mam.category cec ON CEC.CATEGORY_ID = CES.CATEGORY_ID


SELECT cec.year, ceo.*
  FROM mam.options ceo
  JOIN mam.subcategory ces ON CES.SUBCATEGORY_ID = CEO.SUBCATEGORY_ID
  JOIN olr.iep_cost_est_category cec ON CEC.CATEGORY_ID = CES.CATEGORY_ID

По словам друга, представления в oracle на самом деле быстрее для целей кэширования.Это правда?Что насчет postgresql?Я пробовал Google и StackOverflow (самый близкий из них MS SQL).

Ответы [ 2 ]

9 голосов
/ 21 января 2011

Представления

Представления, что означает нематериализованные представления, не кэшируются.Это просто подготовленный оператор SQL, который выполняется вместо ссылки на представление в запросе.Думайте о них как о макросах или переменных, содержащих оператор SELECT, содержащийся в представлении.

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

Natural JOINs

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

      SELECT cec.year, ces.*
        FROM mam.subcategory ces
NATURAL JOIN mam.category cec

Синтаксис не одобряется (хотя и является ANSI), поскольку в лучшем случае он неоднозначен и оставляет вас открытым для проблем, если:

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

Заключение

Нематериализованные представления в значительной степени не имеют отношения к синтаксису JOIN.Данные и индексирование будут оказывать большее влияние на производительность.

6 голосов
/ 21 января 2011

Представления иногда могут помочь с кэшированием слегка .Основой является то, что

SELECT a.name, b.zipcode 
FROM table_a a JOIN table_b b ON a.id = b.id

- это запрос, отличный от

SELECT a.name, b.zipcode 
FROM table_b b JOIN table_a a ON a.id = b.id

, даже если они логически идентичны.Если оба отправляются в Oracle, они оба попадают в кеш запросов.[В кеше запросов Oracle хранит запросы, поэтому ему не нужно повторять проверки синтаксиса / разрешений и вычислять путь выполнения запроса.] Имея представление, инкапсулирующее объединение table_a и table_b, меньше вероятность завершения нескольких запросовв кеше, которые логически идентичны.

Это часть более общего принципа «Не повторяйся».Если вы повторяете код, вам нужно повторить тестирование и исправление, и у вас есть больше кода, который может пойти не так.Любой выигрыш в производительности - это бонус.Таким образом, у представлений есть свои преимущества, но производительность не является существенной.

...