Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8   вперед  Ctrl      все
 О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Топик навеян периодическими воплями на тему, что "наши временные таблицы - более "временные", чем ваши" ;-) Последний раз тему затронули вчера в соседнем топике. Разговор не ограничивается Oracle и MSSQL, так что апологеты других серверов могут подключаться.

Итак, ведем дискуссию о реализации временных таблиц в различных серверах. Для начала заглянем в SQL-стандарт. Там мы видим во-первых деление на глобальные (далее GTT) и локальные (далее LTT) временные таблицы.

GTT создаются с помощью CREATE GLOBAL TEMPORARY TABLE. Характеризуются глобальной видимостью метаданных (они лежат в общей схеме) и сеансовой видимостью данных. Т.е. наличие GTT видят все, но каждая сессия работает со своей копией данных. Если посмотреть на существующие СУБД, то почти все реализуют (с тем или иным синтаксисом) эту возможность. Исключения - DB2 (DECLARE GLOBAL, однако видимость метаданных сессионная), а также PostgreSQL и MySQL - нет этой фичи вообще. Один нюанс - MSSQL (и полагаю, что Sybase ASE также) разделяет данные GTT между сессиями. Никто больше этого не делает.

LTT бывают <created> и <declared>. Первые создаются через CREATE LTT и характеризуются сессионной видимостью метаданных. Это означает, что две сессии могут создать разные по структуре CLTT с одинаковым имеем. Разумеется, видимость данных тоже сессионная. Oracle не поддерживает CLTT (как минимум в 9i), также как Sybase ASA и InterBase. Второй класс LTT создается через DECLARE LTT и подразумевает видимость (как метаданных, так и данных) только в пределах текущего модуля (SQL client module). Увы, стандартное понятие модуля достаточно туманно/спорно и, похоже, производители предпочитают трактовать DLTT как внутрипроцедурные таблицы. Oracle и MSSQL имеют такую возможность (в том или ином виде), на счет остальных СУБД у меня информации нет.

На практике, лично у меня вообще очень редко возникала необходимость во временных таблицах. И если уж и возникала, то исключительно в GTT (сгенерить данные для сложного отчета процедурой и натравить потом на них Crystal Reports) или в DLTT (если процедурный расчет нельзя выполнить за один прогон исходных данных). Допускаю, что CLTT также могут быть полезны при вынесении логики из базы.

У меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Второй - какого фига мелкомягкие GTT разделяют данные? На кой тогда вообще это надо?

Также хотелось бы услышать о ситуациях, в которых люди применяют временные таблицы. Особенно - почему нелья обойтись без них? Если кто-то хочет поговорить о других вещах, как-то: механизмы хранения временных данных или нюансы отработки ON COMMIT { PRESERVE | DELETE } ROWS - welcome. Если я в чем-то ошибся насчет какой-либо СУБД - поправьте.
23 дек 04, 15:43    [1204973]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
IMHO Oracle не поддерживает локальные временные таблицы, потому-что это фактически DDL в продакт коде, т.е. очень очень плохо. Возможно MSSQL к этому относится терпимее но в Oracle это настоящий гиморой.
23 дек 04, 15:47    [1205002]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кстати, необходимость во временных таблицах вообще в Oracle возникает крайне редко. Практически любой отчет можно сформулировать одним запросом. И даже если запрос получится очень махровым оптимизатор с ним справится. До введения аналитических функций (8i) проблему представляли запросы типа "нарастающий итог", что касается "деревянных" расширений, они есть уже в 7-ке.
23 дек 04, 15:50    [1205017]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Yo!
Guest
автор
Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт?


во первых идеологическая проблема, на временые таблицы оракла можно вещать вью и тригеры, а это значит что дефиниция этой таблицы должна быть в словаре базы и соответственно не может быть разной для разных пользователей.
наверника если задуматся это можно было бы как-то обойти с помощью синонимов и т.п. но поскольку мало кто придумал задачу в которой бы такое понадобилось, то и решать эту "проблему" видно не собираются.
23 дек 04, 15:57    [1205060]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Gluk (Kazan)
IMHO Oracle не поддерживает локальные временные таблицы, потому-что это фактически DDL в продакт коде, т.е. очень очень плохо. Возможно MSSQL к этому относится терпимее но в Oracle это настоящий гиморой.


Об этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Думать все начинают уже после того, как что-то не получилось :-(
23 дек 04, 16:00    [1205079]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Yo!
во первых идеологическая проблема, на временые таблицы оракла можно вещать вью и тригеры, а это значит что дефиниция этой таблицы должна быть в словаре базы и соответственно не может быть разной для разных пользователей.


Это не ответ. Ты описал возможности Оракла в отношении GTT. Кто им мешает ввести ограничения для LTT? И вообще, почему нельзя разграничить видимость словаря базы? Например, через namespace/schema + session_id? Т.е. это не идеологическая проблема, по крайней мере, в этом ракурсе.
23 дек 04, 16:03    [1205104]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Oracle не поддерживает CLTT (как минимум в 9i), также как Sybase ASA и InterBase.

В Sybase ASA есть - CREATE TABLE #TableName в целях совместимостью с MSSQL. Но этим пользоваться не интересно, так как на такую форму записи не навесишь различные параметры времянки (тот же флаг NOT TRANSACTIONAL), как в DECLARE LOCAL TEMPORARY TABLE.

автор
Увы, стандартное понятие модуля достаточно туманно/спорно и, похоже, производители предпочитают трактовать DLTT как внутрипроцедурные таблицы. Oracle и MSSQL имеют такую возможность (в том или ином виде), на счет остальных СУБД у меня информации нет.

В ASA cуществует понятие блоков видимости и атомарности. Так что в этом коде:
BEGIN
  BEGIN
    DECLARE LOCAL TEMPORARY TABLE @T (id int);
    SELECT * FROM @T;
  END;

  SELECT * FROM @T;
END;
второй SELECT вернет ошибку о несуществующей @T. В отличие от переменных, времянки имеют область видимости в вложенных вызовах других процедур, это же относиться и к триггерным Inserted/Deleted, которые выступают как полноценные времянки, так что обьявленная в процедуре или триггере времянка спокойно и везде видиться на всех вложенных уровнях вызовов.

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

То же самое один в один. Плюс иногда полезно через DLTT предварительно загнать небольшое кол-во многократно используемых и рассчитываемых данных, которые фигурируют в очень сложном и большом запросе, чтобы оптимизатор лишний раз не сходил с ума и видно, что от этого только выиграешь.

автор
Также хотелось бы услышать о ситуациях, в которых люди применяют временные таблицы. Особенно - почему нелья обойтись без них? Если кто-то хочет поговорить о других вещах, как-то: механизмы хранения временных данных или нюансы отработки ON COMMIT { PRESERVE | DELETE } ROWS - welcome. Если я в чем-то ошибся насчет какой-либо СУБД - поправьте.

В ASA помимо ON COMMIT { PRESERVE | DELETE } есть еще NOT TRANSACTIONAL. Вот и вся разница. Остальное тоже самое. Так же можно и триггера на GTT катать, очень удобно иногда.

автор
У меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт? Второй - какого фига мелкомягкие GTT разделяют данные? На кой тогда вообще это надо?

Гм - зачем нужны CLTT, когда есть GTT - это гораздо удобнее. Думаю если бы у MSSQL и ASE были GTT, никто этими CLTT и не пользовался бы. Во вторых разделяют, потому как механизм так криво реализован по моему личному мнению. В ASE кстати номер с ## (глобальными MS времянками) вообще не прокатывает - нет там такого. Плюс эти ## у MSSQL имеют нехорошую тенденцию удалятся при завершении той сессии, которая их создала, так что лично я так и не смог придумать им хоть какое то разумное применение (может и плохо думал, кто знает).
23 дек 04, 16:06    [1205122]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Gluk (Kazan)
Кстати, необходимость во временных таблицах вообще в Oracle возникает крайне редко. Практически любой отчет можно сформулировать одним запросом. И даже если запрос получится очень махровым оптимизатор с ним справится.


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

ЗЫ. Щаз придут фанаты сиквела и все опровергнут ;-)
23 дек 04, 16:07    [1205128]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
segun
Member

Откуда: Москва
Сообщений: 504
где-то неподалеку слышен тоскливый вой бродячей собаки..
и вот, гаснет свет и двери начинают меедленно открываться..
неужели это снова пришли ОНИ??

страшно? :)
23 дек 04, 16:16    [1205172]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
dimitr
Об этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма. Думать все начинают уже после того, как что-то не получилось :-(


Нууу не надо быть Энштейном, чтобы понять - что одна СУБД воспринимает хорошо, то другая может воспринимать очччень плохо. Только не надо сразу говорить, что это минус. Это может быть и плюс
23 дек 04, 16:17    [1205184]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
dimitr
Тут согласен, хотя оптимизатор зачастую все же не справляется. Т.е. получается, что богатый набор языковых фич в большинстве случаев отменяет необходимость во временных таблицах. Но так ли это на практике?


Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :)
23 дек 04, 16:19    [1205196]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
я GTT в DB2 использую как правило в качестве меток к записям в пользовательской выборке. Присоединяешь к основной таблице левым джойном - и красота...)
23 дек 04, 16:19    [1205198]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
ASCRUS
Гм - зачем нужны CLTT, когда есть GTT - это гораздо удобнее.


Чтобы создавать нужные таблицы динамически в сессиях, не заботясь о том, есть ли уже другие с такми же именем. Для меня это нонсенс, правда, но многие по-другому думать не умеют, похоже ;-)

К слову, искренне рад за ASA. Хоть и не люблю блокировочники вообще (говорил уже, что готовить не умею), но ASA мне наиболее приятен.
23 дек 04, 16:20    [1205207]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
segun
Member

Откуда: Москва
Сообщений: 504
в MS SQL глобальные временные таблицы лично я никогда не использовал (за ненадобностью, ИМХО), а вот локальные - да. Иногда, для помощи оптимизатору, я разбивал большой запрос с джоинами к многомилионным таблицам на пару-тройку более простых и промежуточные результаты записывал в локальную врем.таблицу. Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась.
23 дек 04, 16:22    [1205219]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Локальные временные таблицы теоретически могут пригодиться, если каждый раз требуется таблица ДРУГОЙ структуры, но я не могу придумать задачу, в которой это было-бы НЕОБХОДИМО. И в Oracle, минусы от такой фичи существенно перевесят плюсы.
23 дек 04, 16:24    [1205238]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
segun
в MS SQL глобальные временные таблицы лично я никогда не использовал (за ненадобностью, ИМХО), а вот локальные - да. Иногда, для помощи оптимизатору, я разбивал большой запрос с джоинами к многомилионным таблицам на пару-тройку более простых и промежуточные результаты записывал в локальную врем.таблицу. Потом появились переменные типа table и необходимость даже в локальных врем таблицах еще больше снизилась.

Аналогично.

-- Tygra's --
23 дек 04, 16:24    [1205245]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
Gluk (Kazan)
Если оптимизатор в КОНКРЕТНОМ случае не справляется, это задача для тюнинга :)


Или для баг-репорта производителю :)
23 дек 04, 16:26    [1205263]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
На моей (не очень богатой) практике не было случая, когда не удавалось найти какое-либо приемлимое решение НА МЕСТЕ
23 дек 04, 16:28    [1205277]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
В MS SQL одно из наиболее частых применений временных таблиц - сказать
INSERT INTO #ttable
EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно>

Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ?
23 дек 04, 16:29    [1205290]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7008
gardenman
я GTT в DB2 использую как правило в качестве меток к записям в пользовательской выборке. Присоединяешь к основной таблице левым джойном - и красота...)


Кстати да, про такое применение я и забыл. Вполне удобно.
23 дек 04, 16:30    [1205294]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
dimitr
У меня всего два вопроса. Первый - почему Oracle (и кое-кто еще) не поддерживают CLTT? Есть какие-либо технические проблемы? Или просто сочли ненужными и забили болт?

Я бы сказал так: техническая возможность есть, но я отлично понимаю нежелание их делать.

Оракл стремится перенести максимум нагрузки на этап компиляции кода и соответственно максимально разгрузить (и за счет этого убыстрить) этап выполнения. В ситуации, когда одна процедура создает таблицу, а другая делает из нее селект, о таком желании можно забыть.

Соответственно, технически такая возможность есть (через динамический SQL), но это надо делать специально. Грубо говоря, компилятор не встраивает поддержку заведомо неэффективного режима.

Мало того: уже достаточно давно существует поддержка nested tables, которые аналогичны подобным "сугубо временным" таблицам. То есть: из них можно делать селекты, также с ними можно работать как с массивами.

dimitr
Об этом я тоже думал. И в курсе, насколько Оракл это не любит. Но фишка в том, что термин "очень плохо" не дойдет до людей, у которых СУБД такие вещи принимает легко. Для них это норма.

Вопрос в том, что эти люди даже не пытаются думать об эффективности кода, который пишут. Перейдя на Оракл, люди - типично - начинают пытаться работать с ним именно так, не пытаясь разобраться, хорошо это (для Оракла) или плохо. Поэтому, полагаю, они и на родном сервере не задавались этим вопросом.

В такой ситуации я всячески поддерживаю нежелание встраивать "фичу для торможения". Тем паче, что ни малейшей необходимости нет.
23 дек 04, 16:45    [1205379]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Alex.Czech
Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ?


А явные курсоры в Oracle НЕ ЕСТЬ ЗЛО
23 дек 04, 16:48    [1205398]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Gluk (Kazan)
Alex.Czech
Кстати, как такие проблемы решают в Оракл, я не совсем понимаю до сих пор. Юзать REF CURSOR ? Дык по нему потом пройтись придется с песнями и плясками курсором, чтобы заюзать в своем запросе в качестве элемента; или я неправ ?


А явные курсоры в Oracle НЕ ЕСТЬ ЗЛО


Да лана... пройтись курсором по тыще строчек - не есть зло ? :) Или есть все-таки какая-то возможность bulk collect-а из REF CURSOR ?
23 дек 04, 16:50    [1205414]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Зависит от конкретной задачи. Ходить по 1000 строчек и в MSSQL не гут.
Давайте не будем разводить на эту тему флейм, тема так хорошо началась :)
23 дек 04, 17:00    [1205485]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Я не фанат, просто мне интересно как можно что-то делать без временных таблиц. Вот пример куска реального триггера на изменение остатков при вставке проводок
автор
declare @accstm_c table(
bln varchar(15),
fond varchar(15),
date datetime,
acc varchar(30),
s dec(19,6),
d dec(19,6),
c dec(19,6))

insert @accstm_c
select bln, fond, date, dacc acc, summa s, summa d, @nil c
from inserted
insert @accstm_c
select bln, fond, date, cacc, -summa,@nil,summa
from inserted
insert @accstm_c
select bln, fond, date, dacc, -summa,-summa,@nil
from deleted
insert @accstm_c
select bln, fond, date, cacc, summa,@nil,-summa
from deleted

declare @accstm_p table(
bln varchar(15),
fond varchar(15),
date datetime,
acc varchar(30),
s dec(19,6),
d dec(19,6),
c dec(19,6))

insert @accstm_p
select bln,fond,date, acc, sum(s) s,sum(d) d,sum(c) c
from @accstm_c -- изменение остатка,
group by bln,fond,date,acc -- дебета и кредита при проводке

insert @accstm_p
select bln,fond,'20651031', acc, 0,0,0
from @accstm_p
group by bln,fond, acc

declare @accstm_d table(
bln varchar(15),
fond varchar(15),
acc varchar(30),
date1 datetime null,
date2 datetime null)

insert into @accstm_d
select p.bln,p.fond,p.acc, p.date date1, min(s.date) date2
from @accstm_p p, @accstm_p s -- выбираются интервалы дат
where p.bln=s.bln -- для вычисления поправок остатков
and p.fond=s.fond
and p.acc=s.acc
and p.date<s.date
group by p.bln,p.fond,p.acc, p.date


declare @accstm_s table(
bln varchar(15),
fond varchar(15),
acc varchar(30),
date1 datetime null,
date2 datetime null,
s dec(19,6))

insert into @accstm_s
select p.bln,p.fond,p.acc,d.date1 date1, d.date2, sum(p.s) s
from @accstm_p p, @accstm_d d
where p.bln=d.bln -- для вычисления поправок остатков
and p.fond=d.fond
and p.acc=d.acc
and d.date1>=p.date
group by p.bln,p.fond,p.acc, d.date1, d.date2

declare @accstm_n table(
bln varchar(15),
fond varchar(15),
date datetime null,
acc varchar(30),
s dec(19,6))

insert into @accstm_n
select bln,fond,date,acc,@nil s -- выборка недостающих состояний
from @accstm_p p -- счетов
where date<>'20651031'
and (s<>0 or d<>0 or c<>0)
and not exists(select * from AccState s
where p.bln=s.bln
and p.fond=s.fond
and p.acc=s.acc
and p.date=s.date)

declare @accstm_v table(
bln varchar(15),
fond varchar(15),
date datetime,
acc varchar(30),
dp datetime null)

insert into @accstm_v
select n.bln,n.fond,n.date,n.acc, max(s.date) dp
from @accstm_n n, AccState s
where n.bln=s.bln
and n.fond=s.fond -- выборка дат предыдущих движений
and n.acc=s.acc -- для счетов с недостающими остатками
and n.date>s.date
group by n.bln,n.fond,n.date,n.acc


update @accstm_n
set s=s.s -- вычисление остатков
from @accstm_n n, AccState s, @accstm_v v
where n.bln=v.bln
and n.fond=v.fond
and n.acc=v.acc
and n.date=v.date
and v.bln=s.bln
and v.fond=s.fond
and v.acc=s.acc
and v.dp=s.date


insert AccState(bln,fond,date, acc,dt,cr,s)
select bln,fond,date,acc,0,0,s -- вставка недостающих состояний
from @accstm_n -- счетов

update AccState -- пересчет остатков
set s=a.s+s.s
from AccState a, @accstm_s s
where a.bln=s.bln
and a.fond=s.fond
and a.acc=s.acc
and a.date>=s.date1 and a.date<s.date2

update AccState -- пересчет оборотов
set dt=dt+d, cr=cr+c
from AccState a, @accstm_p p
where p.bln=a.bln
and p.fond=a.fond
and p.acc=a.acc
and a.date=p.date
and p.date<>'20651031'

delete AccState -- удаление ненужных состояний
from AccState a, @accstm_p p
where p.bln=a.bln
and p.fond=a.fond
and p.acc=a.acc
and a.date=p.date
and p.date<>'20651031'
and cr=0 and dt=0

Понимаю что разбираться в таком количестве лень. Суть в том что данные последовательно обрабатываются и в конце используются для модификации рабочих таблиц. При чем используются не по одному разу.

Кое-какие запросы можно было бы объеденить через UNION. Но если объединять очень много - читабельность падает.

Наверняка нечто подобное(последовательная обработка) приходится делать и на Оракле. Как это обычно делается? Где хранятся промежуточные результаты?

Насчет глобальных таблиц - я их использую только в одном случае: допустим когда чего-то понасчитал в обычные временные таблицы, а потом надо это получить в Эксель. Проще всего это сделать через GTT.
23 дек 04, 17:07    [1205533]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить