Comments 30
Отлично, так и надо писать статьи про обновления — подробно, с примерами, а не просто перечисление новых фич.
Интересно, спасибо.
Материализированное представление — интересная штука, но где их можно применить на практике? Судя по плану запроса и индексам, это просто аналог обычной таблицы, данные в которой приходится так же обновлять. Хотя проще иметь один объект-представление, нежели создавать таблицу + функцию для её обновления.
Материализированное представление — интересная штука, но где их можно применить на практике? Судя по плану запроса и индексам, это просто аналог обычной таблицы, данные в которой приходится так же обновлять. Хотя проще иметь один объект-представление, нежели создавать таблицу + функцию для её обновления.
Первое, что пришло в голову в момент прочтения статьи: есть база регионов присутствия провайдера, есть база районов в них, есть населенных пунктов, есть улиц и домов. По house_id формирую строку адреса, но пока приходится хранить в абонентах как строку-адрес, так и house_id для упрощения поиска. Далее, мы пишем улицы без сокращений, но некоторые названия так и хочется сократить, т.к. длина названия стремится к ширише монитора )) (погуглите улицы в Вышнем Волочке). С помощью материализованного представления я смогу собрать различные написания адресов в строки и подкрепить их к house_id. Плюсы очевидны.
Оффтоп: слоны зачетные ))
Оффтоп: слоны зачетные ))
Там где используются тяжёлые запросы, а данные меняются сравнительно редко. Как у нас в проекте, например. Нам просто обязательно приходится эмулировать материализованные представления, пока нельзя будет перейти на 9.3, где это делается так просто и лаконично.
> Материализированное представление — интересная штука, но где их можно применить на практике?
Например, в таблицах, собирающих статистику. Если статистика нетривиальная (или собирать ее надо на большом объеме данных), то обычное представление будет выдавать результат за совершенно неудовлетворительное время.
Например, в таблицах, собирающих статистику. Если статистика нетривиальная (или собирать ее надо на большом объеме данных), то обычное представление будет выдавать результат за совершенно неудовлетворительное время.
Во, есть такое.
Обычно делается сводная таблица, которая заполняется длительное время, и это никак нельзя сделать по клиентскому запросу (время ожидания составляет десятки минут), формируем её обычно в конце отчётного периода, либо, если очень срочно нужно, в любое время по запросу пользователей. А клиент просто берёт из неё готовые данные.
Реализовано с помощью обычной таблицы и функции, её заполняющей.
Обычно делается сводная таблица, которая заполняется длительное время, и это никак нельзя сделать по клиентскому запросу (время ожидания составляет десятки минут), формируем её обычно в конце отчётного периода, либо, если очень срочно нужно, в любое время по запросу пользователей. А клиент просто берёт из неё готовые данные.
Реализовано с помощью обычной таблицы и функции, её заполняющей.
В __Оракле__ используем хранимые представления с обновлением как по ON UPDATE так и по таймеру (раз в час).
В какой то мере заменяет сфинкс для поиска в большом объёме данных по «многоджойнутым» запросам и, по сравнении со сфинкс, решает проблемы доступа к отдельным записям путём дополнительного join на таблицы привилегий, которые у каждого пользователя могут отличаться.
В общем, мощная и удобная штука.
Хорошо, если такое же теперь есть теперь в PostgreSQL.
В какой то мере заменяет сфинкс для поиска в большом объёме данных по «многоджойнутым» запросам и, по сравнении со сфинкс, решает проблемы доступа к отдельным записям путём дополнительного join на таблицы привилегий, которые у каждого пользователя могут отличаться.
В общем, мощная и удобная штука.
Хорошо, если такое же теперь есть теперь в PostgreSQL.
Великолепная статья. Спасибо. А почему триггер на обновление представления из примера выполняется «for each row»? Разве недостаточно будет выполнить обновление для операции в целом?
Да уж, после прочтения таких новостей крайне грустно возвращаться к MySQL.
Oracle совершенно не шевелится с добавлением чего-то действительно полезного.
Oracle совершенно не шевелится с добавлением чего-то действительно полезного.
Ну всё, ребята, сейчас будут PHP гуру насиловать JSONом postgres.
Как по мне, это они перестарались. Может мне может кто-нибудь объяснить, зачем в базе данных этот тип?
Как по мне, это они перестарались. Может мне может кто-нибудь объяснить, зачем в базе данных этот тип?
А почему бы и нет. У многих NoSQL баз данных отпал такой аргумент «schema-less» против PostgreSQL :)
Я могу. Мне его сильно не хватало. Ибо обычного hstore маловато будет.
Есть такая штука как OpenStreetMap. Точнее его база. У узлов описывающие географические объекты есть таги. К примеру маяки.
Нужно описать их тип, световые сектора их цвета, частоту мерцания. А у моста или порта этоти таги совсем другие.
Т.е. конкретно выделить схему атрибутов различных типов объектов нельзя. Точнее можно и нужно но спроецировать ее на базу очень гемморойно.
Сейчас атрибуты можно хранить в плоском виде т.к hstore не может в качестве значения использовать другой hstore. в результате чего ключи выглядят так seamark:light:1:color=>red. Что не очень удобно и для индексации и для разбора. JSON тут более естественен.
Есть такая штука как OpenStreetMap. Точнее его база. У узлов описывающие географические объекты есть таги. К примеру маяки.
Нужно описать их тип, световые сектора их цвета, частоту мерцания. А у моста или порта этоти таги совсем другие.
Т.е. конкретно выделить схему атрибутов различных типов объектов нельзя. Точнее можно и нужно но спроецировать ее на базу очень гемморойно.
Сейчас атрибуты можно хранить в плоском виде т.к hstore не может в качестве значения использовать другой hstore. в результате чего ключи выглядят так seamark:light:1:color=>red. Что не очень удобно и для индексации и для разбора. JSON тут более естественен.
Затем чтобы в таблице не держать 100 полей. Например атрибуты пользователя, коих может быть оооочень много.
очень интересно, спасибо.
UFO just landed and posted this here
LATERAL больше всего радует, с этой конструкцией много формулировок запросов должно упроститься.
В следующей версии обещают условия внутри вызова агрегатных функций — совсем прелесть.
В следующей версии обещают условия внутри вызова агрегатных функций — совсем прелесть.
А я хочу пакеты… а их всё нет и нет =(
> Note that materialized views cannot be auto-refreshed; refreshes are not incremental; and the base table cannot be manipulated
21 год назад (1992 г), у Oracle 7 уже был fast refresh (incremental refresh в терминах пострге).
Пруф — docs.oracle.com/cd/A57673_01/DOC/server/doc/SQL73/ch4a.htm#toc100
Постгре, шажочек за шажочком, гонится за ораклом, отставая на десятилетия. Всё-равно молодцы.
21 год назад (1992 г), у Oracle 7 уже был fast refresh (incremental refresh в терминах пострге).
Пруф — docs.oracle.com/cd/A57673_01/DOC/server/doc/SQL73/ch4a.htm#toc100
Постгре, шажочек за шажочком, гонится за ораклом, отставая на десятилетия. Всё-равно молодцы.
В частных случаях incremental refresh несложно сделать руками. По настоящему ракетная наука, это Qwery Rewrite, позволяющий автоматически подставлять Materialized View в SQL-запросы пользователя, переписывая их.
Sign up to leave a comment.
PostgreSQL 9.3 Что нового?