Не нравится, что императивщина прорвалась в SQL (декларативный язык). Всё же решение о материализации должен принимать оптимизатор, а не разработчик. Иначе получается тот же самый хинт, только с приятным синтаксисом
Спасибо! Курсы — огонь! Просмотрел все. Нет ли планов выпустить теоретическую часть курсов в виде книги? Схожей по духу с книгой Тома Кайта «Архитектура Oracle для профессионалов»
Вот это действительно звучит круто! Особенно в случаях, когда индексы создаются только для поддержки ограничений целостности. Теперь они смогут выполнять ещё и «полезную» работу. Жаль, что это не отмечено в основном тексте статьи
Правильно ли я понимаю, что такой подход сводит на нет оптимизацию HOT-update в случае, если изменяется «включенное» поле? Так же не очень понятно на счёт работы MVCC. PostgreSQL в худшем случае все равно придётся сходить в таблицу, чтобы узнать xmin/xmax?
Говоря о PostgreSQL почти все неоспоримые причины не делать так Вы уже описали: производительность и работа с транзакционными пулами соединений. Есть ещё некоторые. Например, описанный в статье подход не будет работать на standby, потому что DDL влечет за собой операции записи. Также любой DDL изменяет системный каталог, и в случае PostgreSQL автовакууму приходится на это реагировать. Изменения системного каталога (здесь я не уверен на счет временных таблиц и функций) пишутся в WAL, который потом проигрывается на standby (по сути проигрывать и нечего). Реализация временных таблиц в PostgreSQL оставляет желать лучшего: например, их не отслеживает автовакуум, что в некоторых случаях может привести к падению всего кластера.
Есть ещё некоторые «религиозные» соображения. Например, код хранимых процедур должен изменяться согласовано со схемой данных, а схема данных постоянная, а не временная (как-то не логично временным кодом ходить в постоянную схему данных). Наверняка, временный код сложнее держать в согласованном со схемой данных состоянии, чем постоянный код. Это утверждение абсолютно справедливо для Oracle, где код хранимых процедур компилируется. С другой стороны, если возникла потребность изменить хранимую процедуру только для части потребителей (как у Вас в примере), то такая хранимая процедура вероятно нарушает принцип единой ответственности, а также принцип открытости/закрытости (насколько он вообще применим к процедурным языкам).
Все вышесказанное справедливо для PostgreSQL и в некоторых частях для Oracle, у которого, к слову, вообще нет транзакционного DDL. Возможно, в случае с Tarantool описанный Вами подход приемлем (или даже предпочтителен) для решения поставленной задачи
В «больших» БД, в PostgreSQL, например, существует сессионное хранилище (аналог) для данных CREATE TEMPORARY TABLE. Было бы замечательно, если бы там появилась возможность создавать и временные функции CREATE TEMPORARY FUNCTION, которые были бы видны только приконнектившемуся клиенту и удалялись бы после отсоединения.
В PostgreSQL существует возможность создания временных функций. Для этого их нужно создавать в схеме pg_temp (кстати говоря, временные таблицы создаются там же).
Пример:
(сессия 1):
postgres=# create function pg_temp.universal_answer() returns integer language sql as
postgres-# $func$
postgres$# select 42;
postgres$# $func$;
CREATE FUNCTION
(сессия 2):
postgres=# create function pg_temp.universal_answer() returns integer language sql as
postgres-# $func$
postgres$# select 8;
postgres$# $func$;
CREATE FUNCTION
Способ с составным триггером действительно интересный и похож на кунг-фу. Но для решения повседневных задач, где нужно избежать мутирующих таблиц, лучше использовать хранимые процедуры (если есть такая возможность). Иначе будет не так просто понять почему художники стали ниньзя.
Количество колонок варьируется от типа данных на колонках. Поэтому можно иметь от 250 до 1600 колонок. Такая возможность обусловлена размерами страницы в 8 Кб.
С другой стороны, возможность заводить большое число колонок, никак не оправдывает дизайн схемы данных с большим количеством колонок в таблице в РСУБД. РСУБД для этого не предназначены. Для таких задач есть колоночные СУБД, например Cassandra или Teradata.
Боюсь, что в такой постановке задачи, проблемы будут у любой РСУБД, т.к. они не ориентированы на таблицы с таким числом колонок. В рамках РСУБД такие таблицы обычно преобразовываются по модели Entity–attribute–value (EAV).
Видимо я что-то упустил, когда это в PostgreSQL появилась такая функциональность? Можно ссылку на документацию?
Говоря о PostgreSQL почти все неоспоримые причины не делать так Вы уже описали: производительность и работа с транзакционными пулами соединений. Есть ещё некоторые. Например, описанный в статье подход не будет работать на standby, потому что DDL влечет за собой операции записи. Также любой DDL изменяет системный каталог, и в случае PostgreSQL автовакууму приходится на это реагировать. Изменения системного каталога (здесь я не уверен на счет временных таблиц и функций) пишутся в WAL, который потом проигрывается на standby (по сути проигрывать и нечего). Реализация временных таблиц в PostgreSQL оставляет желать лучшего: например, их не отслеживает автовакуум, что в некоторых случаях может привести к падению всего кластера.
Есть ещё некоторые «религиозные» соображения. Например, код хранимых процедур должен изменяться согласовано со схемой данных, а схема данных постоянная, а не временная (как-то не логично временным кодом ходить в постоянную схему данных). Наверняка, временный код сложнее держать в согласованном со схемой данных состоянии, чем постоянный код. Это утверждение абсолютно справедливо для Oracle, где код хранимых процедур компилируется. С другой стороны, если возникла потребность изменить хранимую процедуру только для части потребителей (как у Вас в примере), то такая хранимая процедура вероятно нарушает принцип единой ответственности, а также принцип открытости/закрытости (насколько он вообще применим к процедурным языкам).
Все вышесказанное справедливо для PostgreSQL и в некоторых частях для Oracle, у которого, к слову, вообще нет транзакционного DDL. Возможно, в случае с Tarantool описанный Вами подход приемлем (или даже предпочтителен) для решения поставленной задачи
В PostgreSQL существует возможность создания временных функций. Для этого их нужно создавать в схеме
pg_temp(кстати говоря, временные таблицы создаются там же).Пример:
(сессия 1):
(сессия 2):
(сессия 1):
(сессия 2):
(сессия 3):
На мой взгляд это возможность неприменима к продакшн-коду, но вполне удобна для разовых скриптов, когда нужно переиспользовать функционал
CREATE UNIQUE INDEX uidx_uniq_justif ON t (justification_id) WHERE status=2 or status=3;
Подробнее можно прочесть здесь
С другой стороны, возможность заводить большое число колонок, никак не оправдывает дизайн схемы данных с большим количеством колонок в таблице в РСУБД. РСУБД для этого не предназначены. Для таких задач есть колоночные СУБД, например Cassandra или Teradata.