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

Откуда: МО Электросталь
Сообщений: 5994
Alex.Czech
В MS SQL одно из наиболее частых применений временных таблиц - сказать
INSERT INTO #ttable
EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно>

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

Один из вариантов решения, предложенного в ASA:
SELECT *
FROM StoredProcedure (@Param1, @Param2);
Если в теле процедуры только SELECT, то она воспринимается как представление и разворачивается в план запроса, если еще какой то код, то она выполняется, автоматом результат передается в внутреннюю рабочую таблицу и уже она далее фигурирует в плане запроса. Использование ХП в запросах было бы неполным, если бы в ASA еще не добавили LATERAL соединение:
SELECT *
FROM Table1 t
  LATERAL StoredProcedure (@Param1 = t.Field1, @Param2 = t.Field2);
Такое соединение позволяет для каждой записи Table1 вызвать процедуру с поддержкой передачи в виде параметров полей запроса. Оптимизация будет выглядеть так же - если в процедуре только SELECT, то он развернется в основной план запроса. Это же соединение можно использовать и для организации подзапросов:
SELECT t1.Field1, g.Max_Field2
FROM Table1 t1,
  LATERAL (
    SELECT Max(Field2) AS Max_Field2
    FROM Table2 t2
    WHERE t2.Field1 = t1.Field1
  ) AS g;
Как видим, фактически LATERAL является аналогом Subquery, внутри которого можно обращаться к полям основной таблицы, который часто применяется в секциях SELECT и WHERE. Однако в отличие от Subquery соединение LATERAL реализовано в оптимизаторе собственным оптимизированным алгоритмом и работает гораздо быстрее из за того, что ASA его разворачивает в основной план запроса и соотвествующе более оптимально использует статистику и индексы при его выполнении. В основном такой способ соединения очень выгоден для разделения сложного запроса, где используются куча подзапросов, в которых множество очень обьемных таблиц и получается выгоднее на записи основного запроса через SingleRowGroup организовать аггрегации через LATERAL, чем уломать оптимизатор всю эту страшную кучу правильно соединить. При правильном использовании можно некоторые запросы ускорять в 10-ки раз, плюс это позволяет почаще отказываться от времянок и держаться в проекте главной линии ASA - никаких хинтов в запросах для СУБД с нулевым администрированием, только оптимизатор вправе решать в зависимости от содержания БД, чего и как лучше (хотя естественно это применимо только к СУБД класса Workgroup, а уж никак к хранилищам данных, где есть живой админ, который всегда лучше знает свою БД).
23 дек 04, 17:10    [1205550]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Alex.Czech
В MS SQL одно из наиболее частых применений временных таблиц - сказать
INSERT INTO #ttable
EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно>

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

Ээ.. Заюзать-то можно как угодно. В том числе и через REF CURSOR, если сильно охота.

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

create table X as select ....

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

Ну а конфликта имен здесь не будет в силу такого понятия, как "схема".

Если же имеется в виду постоянное применение, в "релизном программном коде" - надо пользоваться стандартными средствами, теми же GTT. Локальные средства здесь - прямой источник ошибок.
23 дек 04, 17:10    [1205551]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
ASCRUS
Alex.Czech
В MS SQL одно из наиболее частых применений временных таблиц - сказать
INSERT INTO #ttable
EXEC <какая-то-совсем-чужая-процедура-которую-нагибать-под-себя-страшно-или-невозможно>

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

Один из вариантов решения, предложенного в ASA:
SELECT *
FROM StoredProcedure (@Param1, @Param2);


ASCRUS, я сколько читаю то что вы пишете про Sybase ASA, столько вам завидую белой завистью... потрясающий набор возможностей, безо всякой иронии говорю. С удовольствием бы под него попрограммировал :)
23 дек 04, 17:13    [1205570]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
SergSuper
Наверняка нечто подобное(последовательная обработка) приходится делать и на Оракле. Как это обычно делается? Где хранятся промежуточные результаты?

Хм. Мой триггер остатков в этом не нуждался - впрочем, тут надо сравнивать структуры.

Самое простое - запихнуть эти промежуточные результаты в nested table. Это тип данных, относящийся к "коллекциям" Оракла. Их удобство в том, что с ними можно работать как select-ами, так и обычным программным синтаксисом - доступ по индексу, изменение данных, удаление строки итп.
23 дек 04, 17:14    [1205572]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
softwarer
[quot Alex.Czech]Если же имеется в виду постоянное применение, в "релизном программном коде" - надо пользоваться стандартными средствами, теми же GTT. Локальные средства здесь - прямой источник ошибок.


Именно это. GTT не очень нравятся тем что при широком использовании этой фичи их будет очень много и они будут засорять взор при просмотре объектов БД. Тем, что их надо переносить на промышленную БД при переносе ХП. Впрочем, так себе объяснения, я согласен :)
23 дек 04, 17:15    [1205579]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Oracle это тоже позволяет TABLE и PIPELINED. Кроме того всяческие игрища с bulk collect. Синтаксис конечно ужасный, но кто на это обращает внимание ?
23 дек 04, 17:16    [1205581]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Alex.Czech
Именно это. GTT не очень нравятся тем что при широком использовании этой фичи их будет очень много и они будут засорять взор при просмотре объектов БД. Тем, что их надо переносить на промышленную БД при переносе ХП. Впрочем, так себе объяснения, я согласен :)


В Oracle GTT ОДНА на всех пользователей и на все сеансы, разделяются в ней данные. Так что ничего никому засорять не будет.
23 дек 04, 17:17    [1205589]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Так что ничего никому засорять не будет.

Будет.
23 дек 04, 17:20    [1205604]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
SergSuper
Во первых насколько я понял в Оракле нет возможности на AFTER TRIGGER получить весь набор измененных данных, а для позаписных триггеров времянки не нужны.

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

В третьих не забывайте, что у Оракла INSERT и UPDATE можно обьединить оператором MERGE (за название не ручаюсь), нарастающие спокойно реализуются аггрегатными запросами с использованием специальных OLAP и Windows функций, ну и т.д., т.п. В принципе у меня в ASA то же самое все и после перехода на нее с MSSQL мой код заметно ужался в 10-ки раз, использование времянок стало явлением нечастым (а с каждым ежемесячным паком и ростом уровня оптимизатора я что то помниться давно в коде времянок не обьявлял), по курсорам вообще придеться лезть в BOL и вспоминать как они там правильно обьявляются ... в общем понятно, что от того, что я получил более высокую функциональность, у меня сократилось время на написание кода и танцы с бубнами (этих тьфу тьфу вообще не наблюдается, пока на баги не наткнешься и то в основном танцуешь, чтобы обозначить баг и выслать его разработчикам).
23 дек 04, 17:20    [1205607]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Gluk (Kazan)
Oracle это тоже позволяет TABLE и PIPELINED. Кроме того всяческие игрища с bulk collect. Синтаксис конечно ужасный, но кто на это обращает внимание ?


Принципиально - позволяет. На практике
а) Это уже процедуры, а не функции. Для тех кто скажет "who cares ?" я скажу, что не знаю до сих пор как из ADO получить результат выполнения PL/SQL-функции, не говоря уж о том что ADO не поддерживает параметры типа NESTED TABLE
б) PIPELINED глючит, причем иногда ужасно... я лично имел пример PIPELINED-функции, которая при попытке использования в довольно извращенном виде (SELECT (SELECT * FROM t1 INNER JOIN fn(..) where t1.fid = t2.id) FROM t2) срубала коннекцию (ошибка TNS communication lost), после переписки того же на NESTED TABLE работает помедленнее, но зато ничего не срубает
в) еще что-то было, пока писал первые 2 пункта, забыл третий :)

При этом я хочу сказать, что не ставлю совершенно целью вывести утверждение "Оракл плохой". Оракл хороший, но кой-какие вещи и в нем делаются через жо, особенно когда надо поддержать кросс-плафторменность хотя бы в минимальном объеме (а нам тут надо)
23 дек 04, 17:22    [1205613]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Пункт а следует читать "это уже НЕ процедуры, а функции" :)
23 дек 04, 17:23    [1205618]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Что есть в Вашем понимании кроссплатформенность ?
23 дек 04, 17:24    [1205623]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Gluk (Kazan)
Что есть в Вашем понимании кроссплатформенность ?


Наше ПО работает и на MS SQL, и на Оракл. При этом 90% "системного" кода и 99% прикладного одинаковые
23 дек 04, 17:29    [1205647]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Честно говоря, не ощущаю в Oracle ПРИНЦИПИАЛЬНОЙ разницы между процедурами и функциями. Функции удобнее тем, что при определенных условиях их можно использовать в select, у процедур свои мелкие преимущества.
23 дек 04, 17:30    [1205649]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
softwarer
Самое простое - запихнуть эти промежуточные результаты в nested table. Это тип данных, относящийся к "коллекциям" Оракла. Их удобство в том, что с ними можно работать как select-ами, так и обычным программным синтаксисом - доступ по индексу, изменение данных, удаление строки итп.

Ну та же временная (или и переменная таблица в MS SQL) таблица получается.

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

-- Tygra's --
23 дек 04, 17:31    [1205651]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Gluk (Kazan)
Честно говоря, не ощущаю в Oracle ПРИНЦИПИАЛЬНОЙ разницы между процедурами и функциями. Функции удобнее тем, что при определенных условиях их можно использовать в select, у процедур свои мелкие преимущества.


Я так подозреваю, что вы с ним не через ADO работаете :)
23 дек 04, 17:31    [1205653]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Alex.Czech
ASCRUS, я сколько читаю то что вы пишете про Sybase ASA, столько вам завидую белой завистью... потрясающий набор возможностей, безо всякой иронии говорю. С удовольствием бы под него попрограммировал :)

Я не буду точно утверждать, но по моему все что я пишу про ASA давно присутствует в IBM DB2 :) Такое чувство, что из за теплой дружбы iAnywhere и IBM (а как же иначе - ведь iAnywhere главный разработчик ПО под мобильные решения, четко ориентированные под связку с IBM продуктами) последняя разрешила движение WatcomSQL в свою сторону. Хотя вот недавно опрос проводился менеджерами ASA - в какую сторону совместимости впервую очередь нужно двигаться - MSSQL, Oracle или IBM DB2, большинство пользователей высказалось за Oracle, мотивируя это тем, что частенько ASA используется именно в связке с консолидированными хранилищами данных на Оракле. Хотя лично я не представляю, как это можно достигнуть большой совместимости между блокировочником и версионником - все равно способы написания кода будут существенно различаться, да и обычно на верхнем уровне и нижнем не требуется аналогичная функциональность - у каждого уровня свои задачи и своя реализация этих задач.
23 дек 04, 17:33    [1205660]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
А что, ADO селект из функции забракует? И даже с Оракловым провайдером?
23 дек 04, 17:33    [1205661]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Alex.Czech
Gluk (Kazan)
Что есть в Вашем понимании кроссплатформенность ?


Наше ПО работает и на MS SQL, и на Оракл. При этом 90% "системного" кода и 99% прикладного одинаковые


А наше на Unix-е и Windows, но мы здесь не этим мереемся
Не верю я в Ваше понимание кроссплатформенности, тут я полностью солидарен с Кайтом. Хотя мне глубоко импонирует как DB2 может работать с гетерогенными БД. Насколько я понимаю, она подстраивается под особенности реализации других СУБД. Во всяком случае так я понял, прошу адептов сильно не пиннать.
23 дек 04, 17:34    [1205664]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
www.fun4me.narod.ru
А что, ADO селект из функции забракует? И даже с Оракловым провайдером?


Гм. В принципе не забракует. Но тут уже пострадает та самая кросс-платформенность. Нужно еще учитывать, что первой была версия под MS SQL :)
23 дек 04, 17:35    [1205668]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
tygra
Вообще получается, что говорить о временных таблицах в разрезе их определения, данного в начале - нехорошо. Надо бы говорить о них в разрезе применения. А по применению получается, что везде они есть в явном или неявном виде


Это вопрос реализации. В Oracle больше возможностей для выбора и следовательно маневра при разработке.
23 дек 04, 17:36    [1205673]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Gluk (Kazan)
Alex.Czech
Gluk (Kazan)
Что есть в Вашем понимании кроссплатформенность ?


Наше ПО работает и на MS SQL, и на Оракл. При этом 90% "системного" кода и 99% прикладного одинаковые


А наше на Unix-е и Windows, но мы здесь не этим мереемся
Не верю я в Ваше понимание кроссплатформенности, тут я полностью солидарен с Кайтом. Хотя мне глубоко импонирует как DB2 может работать с гетерогенными БД. Насколько я понимаю, она подстраивается под особенности реализации других СУБД. Во всяком случае так я понял, прошу адептов сильно не пиннать.


Это не мое понимание, это реальность данная нам в ощущениях. Если мы сегодня сделаем 2 проекта - один под MS SQL, другой под Оракл, оно наверняка заработает быстрее, но завтра мы все тут и подохнеми :) Хотя постепенно несомненно к этому дело идет
23 дек 04, 17:37    [1205676]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
автор
Гм. В принципе не забракует. Но тут уже пострадает та самая кросс-платформенность. Нужно еще учитывать, что первой была версия под MS SQL :)


В принципе, преобразование вызова exec proc(...) в вызов select * from TABLE(proc(...)) - это достаточно простая операция. Можно автоматически сделать или IF поставить.
23 дек 04, 17:38    [1205682]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Alex.Czech

Это не мое понимание, это реальность данная нам в ощущениях. Если мы сегодня сделаем 2 проекта - один под MS SQL, другой под Оракл, оно наверняка заработает быстрее, но завтра мы все тут и подохнеми :) Хотя постепенно несомненно к этому дело идет


Видите, Вы тоже согласны с Кайтом - должна быть прослойка инкапсулирующая платформенно-зависимые детали реализации :)
23 дек 04, 17:43    [1205696]     Ответить | Цитировать Сообщить модератору
 Re: О временных таблицах замолвите слово...  [new]
Alex.Czech
Guest
Gluk (Kazan)
Alex.Czech

Это не мое понимание, это реальность данная нам в ощущениях. Если мы сегодня сделаем 2 проекта - один под MS SQL, другой под Оракл, оно наверняка заработает быстрее, но завтра мы все тут и подохнеми :) Хотя постепенно несомненно к этому дело идет


Видите, Вы тоже согласны с Кайтом - должна быть прослойка инкапсулирующая платформенно-зависимые детали реализации :)


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