(Переезжаю с SQL Server)

Какая best practice использования временных таблиц?
Например,
есть функция, в которой создается временная таблица
1. с проверкой, если не существует, иначе удаляю все записи из неё
2. если существует, удаляю и создаю

Что будет, если функция будте вызвана одновременно разными клиентами? Будет ли эта таблица видна другим клиентам?
Можно ли/нужно ли пытаться заменять работу с временными таблицами на работу с чем-то другим? массивами?

Maxim BogukРолг Хупин(Переезжаю с SQL Server)

Какая best practice использования временных таблиц?
Например,
есть функция, в которой создается временная таблица
1. с проверкой, если не существует, иначе удаляю все записи из неё
2. если существует, удаляю и создаю

Что будет, если функция будте вызвана одновременно разными клиентами? Будет ли эта таблица видна другим клиентам?
Можно ли/нужно ли пытаться заменять работу с временными таблицами на работу с чем-то другим? массивами?

Временная таблица не видна из других сессий.
Для хранения временных данных ВНУТРИ хранимки лучше не использовать временные таблицы.

PS: я пока не видел задач кроме сложной очень аналитики (где индексы надо делать на временные таблицы и analyze) где было бы использовать временные таблицы.

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

"Лучше не использовать" - ок, но что вместо, в предположении, что одними запросами не обойтись?

Maxim BogukРолг Хупинпропущено...


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

"Лучше не использовать" - ок, но что вместо, в предположении, что одними запросами не обойтись?

Абсолютно любая SQL readonly задача без exceptions и без динамического SQL может быть записана одним SQL запросом (и даже не запросами).
А так - временные данные внутри хранимки если это не миллионы строк - лучше в массивах держать, временные таблицы дорогие очень.

даладно, "абсолютно любая"

qwwqРолг Хупин,

offtop

обратил внимание, что агрегатов по ренджам нету. и мултиренджа, как рез-та агрегирования, тоже в типах не видно. (в сп-гистах агрегаты по геометриям есть, но есть ли "слипающиеся мультиренджи/и т.п. многомерности --не помню)

как агрегировать мультирендж на проходе скл-м надо подумать. по курсору это просто довольно получалось.

но, сопсно, у меня задача была по такому "незаданному" снаружи многомерному мультиренджу сагрегировать. посчитав и его и агрегаты по нему на проходе. или на двух -- вперед и назад. в лоб, простым скл--ем, там размерность была декартова произведения лямов на лямы.


отсутствие табличных переменных в плпгскл -- недоработка пж. имхо.

а матрички хорошо в пайтоне щёлкать, похоже. numpy, scipy --вот это всё. но на прод пайтон ставить стремно.

оффтоп к оффтопу + словоблудие, если просто:

У меня есть
объект->1:N->метаданные->таблицы с метаданными

функция, параметром в которую идет хмл (ДНФ) с параметрами поиска типа:
поле метаданных-тип-операция-значение
...
Операция: =, !=,<,>, like, not like, (fts)
Поле метаданных:прикладное поле, размазанное по нескольким таблицам, в зависимости от типа данных, от того, можэно ли там искать полнотекстово и т.д.
И т.д.
Не хочу двигать часть функционала на клиент, считаю это неправильным, потому всё начинается с разборки хмл и затем в цикле поиск по всем таблицам и как результат возврат списка объектов, у которых метаданные удовлетворяют критериям поиска.

Я могу согласиться, что наверное можно всё грёбнуть запросом*, но в данном случае не вижу как, а вот с временными таблицами/переменными/массивами - вижу