Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 24   вперед  Ctrl
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Я хочу сказать, что подзапрос в NOT EXISTS коррелированный, так что на счет ВСЕГДА не уверен.
В любом случае для каждой результирующей записи будет гарантированно просматриваться весь набор. Это единственный способ убедиться в ОТСУТСТВИИ в наборе соответствующей записи.

Ну и по поводу кэширования страниц, если страницы лога кэшируются так же как данный (в Oracle необходимости в таклм кэшировании напоминаю нет), согласен с Yo
24 июл 07, 13:59    [4428708]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
drev
Предлагаю Вашему вниманию результаты небольшого эксперимента:

Наконец-то :) Я уж думал, заготовка на этот случай пропадет втуне.

Итак, давайте рассмотрим внимательно, какую логику доказательства Вы стоите. Позволю себе изложить без цитат, думаю, претензий к фактам не будет, если что - посмотрим повнимательнее.

Давайте обозначим текущую реализацию как ID, ту, которую предлагаю я - как IUD.

1) Итак, изначально я сказал, что не понимаю преимуществ ID, и обсуждение этого свелось в основном к вопросу эффективности. Вопрос удобства использования мелькает, но снова сводится к эффективности. Итого, зафиксируем спорный вопрос:

2) Я полагаю, что IUD реализация более эффективна, Вы полагаете наоборот - что более эффективна ID (тезис равенства не остаивал никто из нас, так что давайте не будем делать оговорок насчет него)

3) Вы выдвинули тезис о необходимости в ряде случаев update работы с inserted без deleted и о предположительно плохой эффективности IUD в этом режиме. Мы пошли выяснять, когда же это нужно.

4) Вы попробовали привести примеры, когда такой режим нужен, и нашли, что соответствующих ему абстрактных постановок задачи крайне мало.

5) Вы провели эксперимент, который предположительно доказал худшую работу updated (имитированной "inserted с deleted") в ID-режиме. Как результат - "inserted only" предположительно нужен как средство повышения эффективности. То есть выдвинули доказательство, тесно привязанное к текущей реализации в MSSQL - и соответственно, не имеющее никакой силы при обсуждении другой предлагаемой реализации.

Итого, Вы блестяще закольцевали свою логику. Практически Вы сказали следующее: в IUD-режиме надо применять прием из ID-режима потому, что ID-реализация не умеет достаточно хорошо работать в IUD-режиме. Такая схема рассуждений представляется мне малость неубедительной.....

drev
а) Сервер тупо читает одно и тоже место лога дважды, что, ИМХО, несколько странно

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

drev
б) Записи в логе организованы таким образом, что доставать отдельно новые и старые - быстрее,

Сомнительно. Это делает запись в лог много менее эффективной; тогда было бы разумнее вести два лога :)

drev
Возможная причина - другие использования лога.

Ну, фантазировать можно неограниченно. Напомню, все началось с того, что я сказал "не понимаю". При этом я в принципе готов поверить в наличие какого-то убедительного аргумента, но похоже, никто из нас его не знает.
24 июл 07, 14:00    [4428722]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
Что - ещё смешнее:)


Вы не поверите как часто приходится писать смешные, но более оптимальные конструкции
24 июл 07, 14:00    [4428724]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122113
Gluk (Kazan)
pkarklin
Поэтому, как минимум, странно ожидать наличия в таблице inserted в триггере, который сработал на кляузу UPDATE, еще и записей от кляузы INSERT.


Странно, но можно. Проверить можно опытным путем либо дав ссылку на документацию


Я опять про Oracle. (парадоксально , но несмотря на название темы это практически
оффтоп ) . Так вот в Oracle это категорически невозможно

create table tbl_merge
( a number , b number)
/
create or replace trigger trg_ins_merge before insert on tbl_merge 
for each row
begin
dbms_output.put_line('INSERTED !');
end;
/
create or replace trigger trg_upd_merge before update on tbl_merge 
for each row
begin
dbms_output.put_line('UPDATED !');
end;
/
set serveroutput on
/
SQL> insert into tbl_merge values (1,2)
  2  /
INSERTED !

1 Zeile wurde erstellt.

SQL> select * from tbl_merge
  2  /
 
         A          B
---------- ----------
         1          2
 
SQL> 

SQL> merge into tbl_merge using (select 1 a,100 b from dual union all
select 2 a,200 b from dual) dum ON (tbl_merge.a = dum.a)
WHEN NOT MATCHED THEN INSERT VALUES (dum.a, dum.b)
WHEN MATCHED THEN UPDATE SET b = dum.b
/  
UPDATED !
INSERTED !

2 Zeilen integriert.

SQL> select * from tbl_merge
  2  /

         A          B
---------- ----------
         1        100
         2        200

SQL>
24 июл 07, 14:00    [4428726]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
Странно, но можно. Проверить можно опытным путем либо дав ссылку на документацию


Из BOL по 2008:

For every INSERT, UPDATE, or DELETE action specified in the MERGE statement, SQL Server fires any corresponding AFTER triggers defined on the target table, but does not guarantee on which action to fire triggers first or last.

Эксперимент:

IF OBJECT_ID (N'dbo.Departments', N'U') IS NOT NULL
DROP TABLE dbo.Departments;
GO

CREATE TABLE Departments (DeptID tinyint, Deptname nvarchar(30), Manager nvarchar(50));
GO

INSERT INTO Departments VALUES (1, 'Human Resources', 'Margheim'),
(2, 'Sales', 'Byham'), (3, 'Finance', 'Gill'),
(4, 'Purchasing', 'Barber'),(5, 'Manufacturing', 'Brewer');
GO

CREATE TRIGGER it_Departments ON Departments
FOR INSERT, UPDATE, DELETE
AS
  SET NOCOUNT ON
  SELECT COUNT(*) FROM inserted AS Inserted_Count
  SELECT COUNT(*) FROM deleted AS Inserted_Count
GO

IF OBJECT_ID (N'dbo.Departments_delta', N'U') IS NOT NULL
DROP TABLE dbo.Departments_delta;
GO

CREATE TABLE Departments_delta (DeptID tinyint, Deptname nvarchar(30), Manager nvarchar(50));
GO

INSERT INTO Departments_delta VALUES 
(1, 'Human Resources', 'Margheim'), (2, 'Sales', 'Erickson'),
(3 , 'Finance', 'Varkey'),(4, 'Purchasing', 'Barber'), 
(6, 'Production', 'Jones'), (7, 'Customer Relations', 'Smith');
GO

MERGE Departments AS d
USING Departments_delta AS dd
ON (d.DeptID = dd.DeptID)
WHEN MATCHED AND d.Manager <> dd.Manager OR d.DeptName <> dd.DeptName
    THEN UPDATE SET d.Manager = dd.Manager, d.DeptName = dd.DeptName
WHEN NOT MATCHED THEN
    INSERT (DeptID, DeptName, Manager)
        VALUES (dd.DeptID, dd.DeptName, dd.Manager)
WHEN SOURCE NOT MATCHED THEN
    DELETE;
GO

DROP TABLE Departments_delta, Departments

результат:

-----------
2

-----------
0


-----------
2

-----------
2


-----------
0

-----------
1

Все это на:

Microsoft SQL Server code name "Katmai" - 10.0.1019.17 (Intel X86)
May 24 2007 15:26:55
Copyright (c) 1988-2007 Microsoft Corporation
Developer Edition on Windows NT 5.2 <X86> (Build 3790: Service Pack 1)
24 июл 07, 14:04    [4428755]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
pkarklin
2. EXIST\NOT EXIST будет "легче", чем джоин, ибо сервер проверяет только факт наличия записи.


Ага, для каждой строки другой таблицы


Да... Это легче, чем выполнить джоин всех записей, особенно когда каждой записи "другой таблицы" соответствует много записей в проверяемой.
24 июл 07, 14:06    [4428771]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
SergSuper
Мне кажется что вы (участники спора) зря не разделили концепцию СУБД и вопросы реализации.

:)

SergSuper
Вроде выяснили что с точки зрения реализации раздельные inserted и deleted лучше.

Нет. Выяснили, что у текущей реализации MSSQL есть странная просадка производительности, непонятно из-за чего.

SergSuper
но также имеем не очень понятную ситуацию с дублированными именами полей.

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

SergSuper
Для MS сканирование лога - это увеличение производительности,

Можете пояснить мысль?
24 июл 07, 14:14    [4428851]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!

а можно для тех кто не понял: у меня сотни конкурентных юзеров, со скоростью 50 tpc что то пишут в транзакшен лог размером 20Gb, что у меня
1) что за страницы гарантированы мне в кеше ?
2) если в кеше не все страницы как далеко мне нужно прочесать 20 гигобайтовый лог, чтоб гарантировано построить inserted&updated таблички ?


Не пойму, причем здесь общий размер лога и ТЕКУЩАЯ АКТИВНАЯ ТРАНЗАКЦИЯ, в которой мы находимся внутри триггера?!
24 июл 07, 14:16    [4428865]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
pkarklin
особенно когда каждой записи "другой таблицы" соответствует много записей в проверяемой.

Ээ.. это Вы все еще про join по первичному ключу?
24 июл 07, 14:18    [4428873]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Выяснили, что у текущей реализации MSSQL есть странная просадка производительности, непонятно из-за чего.


Гм... Гипотеза о "просадке производительности", пока неподкреплена ничем, кроме теоретических умозаключений.
24 июл 07, 14:18    [4428875]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Gluk (Kazan)
Я хочу сказать, что подзапрос в NOT EXISTS коррелированный, так что на счет ВСЕГДА не уверен.
В любом случае для каждой результирующей записи будет гарантированно просматриваться весь набор. Это единственный способ убедиться в ОТСУТСТВИИ в наборе соответствующей записи.


Безусловно - коррелированный. НА счет "весь набор" не совсем правы. Как только найдется такая запись, дальнейшее сканирование бессмыслено.
24 июл 07, 14:21    [4428897]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
pkarklin
особенно когда каждой записи "другой таблицы" соответствует много записей в проверяемой.

Ээ.. это Вы все еще про join по первичному ключу?


Это будет частный случай. В любом случаи left join с последующей проверкой на NOT NULL будет менее эффективнее, чем NOT EXISTS, за счет того, что сервер не "начитывает" данные для их дальнейшей проверки, а только проверяет факт наличия записей.
24 июл 07, 14:24    [4428917]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Yo.!
Guest
pkarklin

Не пойму, причем здесь общий размер лога и ТЕКУЩАЯ АКТИВНАЯ ТРАНЗАКЦИЯ, в которой мы находимся внутри триггера?!

по ходу дискусии предлагается сканировать ТРАНЗАКШЕН ЛОГ, в связи с этим у меня и вопросы.
я правильно понимаю что вы согласны с ораклоидным станом и тоже считаете это идиотским предложеним ?
24 июл 07, 14:25    [4428920]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67454
Блог
pkarklin
Гм... Гипотеза о "просадке производительности", пока неподкреплена ничем, кроме теоретических умозаключений.

Павел, Вы опять бросаетесь на слова, забыв подумать. Она подкреплена Вашим экспериментом, повторенным Игорем. И Вы, и он доказывали, что обращение в триггере к inserted+deleted оказывается заметно дольше, нежели только к inserted.
24 июл 07, 14:27    [4428941]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
Предлагаю Вашему вниманию результаты небольшого эксперимента:

Наконец-то :) Я уж думал, заготовка на этот случай пропадет втуне.

Итак, давайте рассмотрим внимательно, какую логику доказательства Вы стоите. Позволю себе изложить без цитат, думаю, претензий к фактам не будет, если что - посмотрим повнимательнее.

Давайте обозначим текущую реализацию как ID, ту, которую предлагаю я - как IUD.

1) Итак, изначально я сказал, что не понимаю преимуществ ID, и обсуждение этого свелось в основном к вопросу эффективности. Вопрос удобства использования мелькает, но снова сводится к эффективности. Итого, зафиксируем спорный вопрос:

2) Я полагаю, что IUD реализация более эффективна, Вы полагаете наоборот - что более эффективна ID (тезис равенства не остаивал никто из нас, так что давайте не будем делать оговорок насчет него)

3) Вы выдвинули тезис о необходимости в ряде случаев update работы с inserted без deleted и о предположительно плохой эффективности IUD в этом режиме. Мы пошли выяснять, когда же это нужно.

4) Вы попробовали привести примеры, когда такой режим нужен, и нашли, что соответствующих ему абстрактных постановок задачи крайне мало.

Мда, некорректно. Я просто показал частоту использования только inserted по сравнению с комбинацией inserted/deleted. Всё. Ваша же фраза является сугубо Вашими умозаключениями. И приписыванием мне вещей, которые я не делал. И выводов, к которым я не приходил.


5) Вы провели эксперимент, который предположительно доказал худшую работу updated (имитированной "inserted с deleted") в ID-режиме. Как результат - "inserted only" предположительно нужен как средство повышения эффективности. То есть выдвинули доказательство, тесно привязанное к текущей реализации в MSSQL - и соответственно, не имеющее никакой силы при обсуждении другой предлагаемой реализации.

Итого, Вы блестяще закольцевали свою логику. Практически Вы сказали следующее: в IUD-режиме надо применять прием из ID-режима потому, что ID-реализация не умеет достаточно хорошо работать в IUD-режиме. Такая схема рассуждений представляется мне малость неубедительной.....

drev
а) Сервер тупо читает одно и тоже место лога дважды, что, ИМХО, несколько странно

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

drev
б) Записи в логе организованы таким образом, что доставать отдельно новые и старые - быстрее,

Сомнительно. Это делает запись в лог много менее эффективной; тогда было бы разумнее вести два лога :)

drev
Возможная причина - другие использования лога.

Ну, фантазировать можно неограниченно. Напомню, все началось с того, что я сказал "не понимаю". При этом я в принципе готов поверить в наличие какого-то убедительного аргумента, но похоже, никто из нас его не знает.


1. Вы не заметили одного нюанса в примере. Предсказуемо не заметили. Но к нему мы ещё вернёмся после:

2. Мы рассматриваем текущую реализацию получения inserted и deleted, потому что
у нас нет альтернативной. Вы её не представили. Т.е. , пока Вы не сформулируете алгоритм и соответствующие структуры данных - разговор становится беспредметным. Ввиду того, что для реализации подобной функциональности, с вашей точки зрения нужно часа два, уж представить схему , без имплементации Вам не составит труда, так?
24 июл 07, 14:35    [4429007]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
pkarklin
Гм... Гипотеза о "просадке производительности", пока неподкреплена ничем, кроме теоретических умозаключений.

Павел, Вы опять бросаетесь на слова, забыв подумать. Она подкреплена Вашим экспериментом, повторенным Игорем. И Вы, и он доказывали, что обращение в триггере к inserted+deleted оказывается заметно дольше, нежели только к inserted.


Александр, мне кажется, что обсуждение сейчас скатится на второй круг. Вполне логично, что обращение к двум таблицам будет дольше, чем обращение к одной. Причем невожно, что это таблицы inserted и deleted в триггере или просто другое таблицы бд. Не так ли? Говоря о "заметно дольше", Вы опять, как мне кажется, подспудно подразумеваете наличие таблицы "updated". Причем, по Вашему мнению, ее построение не должно занимать "дольше", чем построение таблиц inserted и deleted (спорное теоретическое предположение на мой взгляд). Именно поэтому я считаю просадку производительности липотетической. Опровергнуть ее может только сравнительный тест при наличии в функционале таблицы updated, чего, я думаю, не будет никогда.
24 июл 07, 14:37    [4429020]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

softwarer wrote:
> Нет. Выяснили, что у текущей реализации MSSQL есть странная просадка
> производительности, непонятно из-за чего.
Это вы об чем?
Я уже ход мысли потерял :(

Posted via ActualForum NNTP Server 1.4

24 июл 07, 14:41    [4429056]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Yo.!

я правильно понимаю что вы согласны с ораклоидным станом и тоже считаете это идиотским предложеним ?


Уважаемые коллеги из стана. Давайте, наконец, не будем усердствовать и приводить "страшные картины апокалиписа" вызревшие в мозгу от больших объемом ВСЕГО лога (аж 20 гигабайт), которые могут и взаправду испугать случайно заглянувших сюда сторонних наблюдателей, что MS SQL для построения таблиц inserted и deleted в триггере начнет сканировать аж ВСЕ 20 гиг лога. Давайте включим мозг и пойдем от противного, что если бы это было так, как Вы это описываете, то вряд ли от MS SQL можно было бы ждать адекватной производительности триггеров.
24 июл 07, 14:44    [4429079]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
locky

softwarer wrote:
> Нет. Выяснили, что у текущей реализации MSSQL есть странная просадка
> производительности, непонятно из-за чего.
Это вы об чем?
Я уже ход мысли потерял :(
Posted via ActualForum NNTP Server 1.4


Напомнило:

-Ты тушканчика видешь?
-Нет.
-А он, есть!
24 июл 07, 14:45    [4429091]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
softwarer

SergSuper
но также имеем не очень понятную ситуацию с дублированными именами полей.

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

в любом случае надо какое-то соглашение что имена должны начинаться допустим с "new_". Не очень хорошо будет выглядеть если есть уже поле "new_id".
Ну и не нравится мне что имена полей будут не такие, какие я объявлял
softwarer

SergSuper
Для MS сканирование лога - это увеличение производительности,

Можете пояснить мысль?

Вспомните что MS SQL блокировочник и представьте что было бы если бы таблица блокировалась пока не закончится репликация

Сообщение было отредактировано: 24 июл 07, 14:57
24 июл 07, 14:48    [4429115]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

pkarklin wrote:
> Это вы об чем?
> Я уже ход мысли потерял :(
А, это про просадку при одновременном inserted/deleted?
дык там всё ясно, на самом деле...

Posted via ActualForum NNTP Server 1.4

24 июл 07, 14:57    [4429187]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
dmidek
Я опять про Oracle. (парадоксально , но несмотря на название темы это практически
оффтоп ) . Так вот в Oracle это категорически невозможно


Простите, а ЧТО Вы проверяли ? В Oracle НЕТ псевдотаблицы inserted.
А меня как раз интересует ее наполнение в случае MERGE, выливающегося в набор вставок и изменений
24 июл 07, 14:58    [4429203]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
SergSuper
softwarer

SergSuper
но также имеем не очень понятную ситуацию с дублированными именами полей.

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

в любом случае надо какое-то соглашение что имена должны начинаться допустим с "new_". Не очень хорошо будет выглядеть если есть уже поле "new_id".
Ну и не нравится мне что имена полей будут не такие, какие я объявлял


А вместо



select id, quantity, new_quantity
from inserted


Придётся писать что-нибудь вроде



select id, quantity, new_quantity
from 
(
select id, quantity, new_quantity from inserted
union all
select new_id, new_quantity, new_new_quantity
from updated) ins_upd

T,e, всё ещё хуже. В приведённом примере колонка new_quantity будет иметь два разных смысла. Особенно весело будет поддерживать такой код.

Мне кажется, идея с префиксами является отражением одного из глобальных пороков Оракл, который в этом топике ещё не адресовали

Глядя на:

select a from b
Невозможно определить, чем является "а" - локальной переменной, колонкой таблицы, вызовом функции.
24 июл 07, 15:03    [4429236]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122113
Gluk (Kazan)
dmidek
Я опять про Oracle. (парадоксально , но несмотря на название темы это практически
оффтоп ) . Так вот в Oracle это категорически невозможно


Простите, а ЧТО Вы проверяли ? В Oracle НЕТ псевдотаблицы inserted.
А меня как раз интересует ее наполнение в случае MERGE, выливающегося в набор вставок и изменений


Я не проверял а показывал срабатывание триггеров в MERGE (Oracle) только по соответствующим
реально происшедшим событиям : UPDATE и INSERT . Рад, что результат оказался для
Вас ожидаемым ...
24 июл 07, 15:04    [4429241]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
locky

А, это про просадку при одновременном inserted/deleted?
дык там всё ясно, на самом деле...
Posted via ActualForum NNTP Server 1.4


locky... Ну уж Вы то... О какой либо просадке производительности можно говорить только по сравнению с чем то. А пока для сравнения предлагается некая гипотетическая теблица updated, затраты на построение которой, опять же, чисто из теоретических умозаключений не берутся, почему то, в счет.
24 июл 07, 15:07    [4429274]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить