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

Откуда: SPb
Сообщений: 5488
2 softwarer, Gluk (Kazan)
Допустим есть абстрактный триггер, который записывает изменения некого поля "a"
create trigger tr on tbl for update
as
insert tbl_log
  select i.id, i.a-d.a
    from inserted i 
     join deleted d on i.id=d.id
Попробуйте написать как бы это выглядело через таблицу updated, просто интересно как вы себе это представляете с точки зрения синтаксиса
17 июл 07, 12:32    [4397361]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
pkarklin
Кстати пример триггера с full outer join и решаемой с помощью него задачи таки не приведен.


К сожалению нет времени на религиозные споры, я лучше понаблюдаю :)
17 июл 07, 12:35    [4397390]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin
Если для Вас это естественно, то тогда какой должна быть структура предлагаемой Вами таблицы updated? Если я правильно Вас понимаю, то кол-во полей базовой таблицы х2, для реализации аналога .old и .new?

Да.

pkarklin
Еще раз - при обращении к inserted и deleted они "не получаются" из лога - эти таблицы и есть по своей сути сам лог,

Павел, не затруднит ли Вас отвечать на написанное?

pkarklin
Т.е. эти таблицы есть интерфейс доступа к уже имеющимся данным и для поддержания нет необходимости в дополнительных ресурсах сервера. Чего не скажешь в отношении предлагаемой Вами таблицы updated.

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

pkarklin
Вот здесь я как раз вижу доп. накладные расходы на поддержание этой таблицы.

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

pkarklin
Нет этой информации. Поэтому и игнорировать нечего.

Вы вряд ли думали над этой фразой.

pkarklin
Обращение к .new .old оно не требует "машинных ресурсов для выполнения"?
На поддержания этой "таблицы updated" в Oracle не требуется "машинных ресурсов"?

Павел, извините, но Вы действуете в стиле того панка, который обходился словами "колесо" и "не жует". Скажите, Вы вообще можете хоть на минуту забыть про существование Оракла и сосредоточиться на MSSQL?

Внимание, повторяю очень подробно. Есть некая реализация таблиц inserted и deleted в MSSQL. Данные об обновленных записях получаются из них с некоторыми дополнительными накладными расходами. По имеющейся пока что информации те же данные в той же структуре можно получать без этих дополнительных расходов. Что приводит к недоумению - почему именно так?

Если можете ответить - замечательно. Если не можете.... ищите в сказанном хоть одно слово "Oracle". Не знаю что за клин в мозгах, честное слово. Полагаю, если бы я на каждое нехвалебное упоминание Oracle отвечал что-нибудь типа "а в MySQL вообще транзакций нет", все бы решили, что я еще больший идиот, нежели выгляжу. Однако практически на любой вопрос "а почему в MSSQL так" следует ответ "а в Oracle что, лучше" - и это считается в порядке вещей.

P.S. Готовым подключиться - я знаю про транзакции в MySQL.

pkarklin
В чем тогда принципиальная разница по сравнению с inserted и deleted тем же самым по сути интерфейсом, который не зависит от того, statement или row level триггер?

Я мог бы ответить, но не хочу, поскольку это только разожжет в Вас совершенно ложное мнение о том, что я стремлюсь их сравнивать.
17 июл 07, 12:39    [4397428]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
drev
Знаете, в чём разница между профессионалом и любителем?

Вовсе не в том, что Вы сказали. Сказанное Вами - в лучшем случае третьестепенная деталь различия.
17 июл 07, 12:40    [4397434]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
drev
Ваша логика слегка напоминает этот стишок.

Спорно, но посмотрим.

drev
Update - это Delete И Insert.

Уточните, пожалуйста, статус этого утверждения. Это Ваша личная точка зрения, это точка зрения Микрософт, это "реализация update в логе", это наконец то, что Вы пытаетесь приписать мне или еще что-нибудь?
17 июл 07, 12:44    [4397471]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
2 softwarer, Gluk (Kazan)
Допустим есть абстрактный триггер, который записывает изменения некого поля "a"


Согласен, относительно full outer был не прав, inner не так напряжно
17 июл 07, 12:48    [4397513]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
SergSuper
Попробуйте написать как бы это выглядело через таблицу updated, просто интересно как вы себе это представляете с точки зрения синтаксиса

Как-нибудь так:

insert tbl_log
select u.new_id, u.new_a-u.old_a
from updated u

2All: прощу прощения, но вынужден на час или два прерваться в беседе.
17 июл 07, 12:49    [4397527]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Павел, не затруднит ли Вас отвечать на написанное?


Хм... Чем Вас не устроил мой ответ на Ваше:

softwarer
В тот момент, когда выполняется оператор update (физически модифицирует данные конкретной строки) существует (тривиальнейше может быть получена) полностью готовая к использованию строка таблицы updated. Также она легко может быть получена из лога.


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


Архитектура лога MS SQL описана в BOL:

Log records for data modifications record either the logical operation performed or before and after images of the modified data. A before image is a copy of the data before the operation is performed; an after image is a copy of the data after the operation has been performed. The steps to recover an operation depend on the type of log record:

Logical operation logged.
-To roll the logical operation forward, it is performed again.
-To roll the logical operation back, the reverse logical operation is performed.
(для insert и delete)
Before and after image logged.
-To roll the operation forward, the after image is applied.
-To roll the operation back, the before image is applied.
(для update)

Таким образом в логе нет "готовой" таблицы updated.

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


Вы не последовательны в своих заключениях. В предыдущих своих постах Вы преподносили в качестве "-" наличию только таблиц inserted и deleted необходимость их джоинить, дабы получить таблицу updated. Согласитесь, что просканить записи лога, прочитав только старые данные и только новые данные по затратам это не тоже самое, что сделать джоин после скана. Причем без какой-либо гарантии, что результаты этого джоина (таблица updated) реально потребуются. Необходим такой джоин разработчику - будь добр - сделай сам. Сервер не тратит на это доп.расходов.

softwarer
Павел, извините, но Вы действуете в стиле того панка, который обходился словами "колесо" и "не жует". Скажите, Вы вообще можете хоть на минуту забыть про существование Оракла и сосредоточиться на MSSQL?


Александр, извините, но в дискуссию я вступил ровно тогда, когда Вами был приведен код и это был код под Oracle.

softwarer
Не знаю что за клин в мозгах, честное слово. Полагаю, если бы я на каждое нехвалебное упоминание Oracle отвечал что-нибудь типа "а в MySQL вообще транзакций нет", все бы решили, что я еще больший идиот, нежели выгляжу. Однако практически на любой вопрос "а почему в MSSQL так" следует ответ "а в Oracle что, лучше" - и это считается в порядке вещей.


Удобство, которое Вы высказали в отношении конструкции .old и .new c просьбой привести аналог на MS SQL, Вы высказывали по отношению к абстрактной СУБД? Нет? По сравнению с MS SQL? Теперь когда я пытаюсь дискутировать с Вами о накладных расходах почему я не имею право сравнивать накладные расходы этих двух СУБД? Опятьдвойные стандарты?

Более того, я пытался изначально показать Вам, что как раз формирование таблицы updated самим сервером на основании данных лога будет доп. расходами, причем без упоминания об Oracle.
в первой части этого поста:

Покритикуйте Оракл 10г

Ну когда Вы завели речь о дополнительных накладных ресурсах на джоин (Вы, конечно, не MS SQL здесь имели ввиду?), естественно, я поинтересовался о накладных расходах на аналогичную операцию в Oracle.

softwarer
Внимание, повторяю очень подробно. Есть некая реализация таблиц inserted и deleted в MSSQL. Данные об обновленных записях получаются из них с некоторыми дополнительными накладными расходами. По имеющейся пока что информации те же данные в той же структуре можно получать без этих дополнительных расходов. Что приводит к недоумению - почему именно так?


Помоему, я уже достаточно наглядно объяснил - почему.

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


Александр, ну а как же можно трактовать Вашу просьбу о приведении аналога триггера на MS SQL?!
17 июл 07, 13:44    [4398029]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЧТо-то видимо меня переклинило, и с комментариями к архитектуре лога я намудрил. К логическими операциям относятся, например, такие, как размещение экстента. INSERT и DELETE, конечно, же фиксируют два состояния.
17 июл 07, 14:08    [4398222]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
drev
Я продолжаю надеятся, уже совсем слабо, что вы поймёте, что описаное вами выше - "снизу вверх"

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

drev
Далее, результатом работы парсера является не то, что вы описали, а некая древесная структура, обычно AST

Глупость, уж простите. Далеко не любой парсер явно строит дерево. Последовательность семантик - это универсальная форма, дерево - один из частных случаев, безусловно, популярный и наиболее удобный в сложных случаях. С "деревянной" точки зрения воспринимайте семантику как команду построить очередной узел дерева.

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

drev
Кого Вы цитируете? Укажите, где я это говорил?

Цитируя я ту фразу, к которой Вы имели замечания (про "токенайзер выделяет"). Учитывая, что лексический анализатор состоит из в Вашей терминологии lexer-а и tokenizer-а из "lexer есть конфигурационный файл" (что Вы подтвердили) следует, что кроме токенайзера "выделять" просто некому и Ваше замечание выглядит... странным.

P.S. К сожалению, информационная насыщенность Ваших сообщений постепенно падает до нуля и единственным их плюсом становится похожий на мой стиль ведения беседы.
17 июл 07, 14:57    [4398679]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin
-To roll the operation forward, the after image is applied.
-To roll the operation back, the before image is applied.
(для update)

Таким образом в логе нет "готовой" таблицы updated.

Может быть я чего-то не понимаю, но приведенную цитату, как мне кажется, следует читать строго наоборот: "в логе есть готовая таблица updated". Наличие before и after images - это по-Вашему не "готовая таблица"?

Вопрос мог бы вызвать следующий аспект - а понимаются ли здесь под images полные наборы данных или только измененные фрагменты? Но если учесть, что эти данные успешно попадают в inserted-deleted - видимо, полные; я прав?

pkarklin
Вы не последовательны в своих заключениях.

Каждый раз, когда Вы приходите к такому заключению, пересмотрите предпосылки :)

pkarklin
В предыдущих своих постах Вы преподносили в качестве "-" наличию только таблиц inserted и deleted необходимость их джоинить, дабы получить таблицу updated. Согласитесь, что просканить записи лога, прочитав только старые данные и только новые данные по затратам это не тоже самое, что сделать джоин после скана.

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

Однако, когда мы берем из лога before & after images, они у нас "уже сджойнены", лежат физически рядом, мы их просто копируем. Если же мы раздергиваем их по разным таблицам, потом приходится их специально джойнить, на что уйдет некоторое количество ресурсов.

pkarklin
Причем без какой-либо гарантии, что результаты этого джоина (таблица updated) реально потребуются.

Кто Вам сказал такую глупость? Не обращается разработчик к таблице - не будет никто строить таблицу. Или MSSQL неленив и сканирует лог вне зависимости от того, упоминаются ли в триггере inserted/deleted или нет?

pkarklin
Необходим такой джоин разработчику - будь добр - сделай сам. Сервер не тратит на это доп.расходов.

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

Кстати, позволю себе такой вопрос. Если делается inserted inner join deleted - сервер сделает один проход по логу или два?

pkarklin
Александр, извините, но в дискуссию я вступил ровно тогда, когда Вами был приведен код и это был код под Oracle.

Факт. Я тогда Вам ответил, что ждал ответа от locky, и та ветка закончилась. Во всяком случае, ни Вы, ни я не высказали желания ее продолжать.

Потом, позднее, я сказал, что не очень понимаю причин отсутствия updated в MSSQL. Ну и при чем тут Oracle? Это было отдельное побочное замечание.

pkarklin
Удобство, которое Вы высказали в отношении конструкции .old и .new

Я не высказывал никакого удобства по отношению к old и new.

pkarklin
Теперь когда я пытаюсь дискутировать с Вами о накладных расходах почему я не имею право сравнивать накладные расходы этих двух СУБД? Опятьдвойные стандарты?

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

"Почему не имеете право...." Хм, мы сравниваем накладные расходы между "реализацией inserted/deleted" и "реализацией inserted/updated/deleted". Какая из них присутствует в Oracle, с чем Вы сравниваете? Заранее отвечу - ни одна. В Oracle - некая третья реализация, и приплетать ее сюда - подмена темы.

pkarklin
Более того, я пытался изначально показать Вам, что как раз формирование таблицы updated самим сервером на основании данных лога будет доп. расходами,

Эта информация была бы очень интересна, но к сожалению, Вы ее как раз и не показали. Просто сказали: "в отношение updated этого не скажешь". В последующем обсуждении, вплоть до первых абзацев этого поста, мы как раз и развиваем ту попытку показать.

pkarklin
Ну когда Вы завели речь о дополнительных накладных ресурсах на джоин (Вы, конечно, не MS SQL здесь имели ввиду?),

С чего Вы так решили? Если я сравниваю текущую реализацию MSSQL с гипотетической реализацией MSSQL, чей джойн, по-Вашему, я имею в виду?

pkarklin
естественно, я поинтересовался о накладных расходах на аналогичную операцию в Oracle.

И чем же это естественно? Вот представьте: сидим мы с Вами, допустим, в Уфе, и прикидываем, как ловчее добраться от улицы Ленина до проспекта Гагарина - пешком или на автобусе. И тут Вы "естественно" интересуетесь, как стоит выполнять аналогичную транзакцию в Санкт-Петербурге.

P.S. Все названия вымышлены, а совпадения случайны.

pkarklin
Помоему, я уже достаточно наглядно объяснил - почему.

Пока, увы, нет. Может, Ваш ответ на первые абзацы таки прояснит.

pkarklin
Александр, ну а как же можно трактовать Вашу просьбу о приведении аналога триггера на MS SQL?!

Во, началось. Прямо хоть в очередной раз посылай Вас на мой сайт читать про логику.

Трактуйте ее как хотите. Я могу рассказать, что это было - тест на внимательность, который я собирался использовать, если беседа с locky пойдет по одному из возможных вариантов. Детали, пардон, уже не вспомню.
17 июл 07, 15:40    [4399077]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Сегодня я врядли найду достаточно времени, дабы ответить развернуто. Скорее всего это будет уже завтра.
17 июл 07, 17:04    [4399877]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Paul Sacks
Member

Откуда:
Сообщений: 1105
10046
Геннадий Евтушенко
Но вобще думаю примерно на одной ступеньке стоят FireBird, ACCESS и Оракл.А MYSQL и SQL Server на уровне чуть выше и по самому качеству продукта и по сложности разработки под среду и обслуживания.



круттттто!!!
17 июл 07, 22:25    [4401158]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Может быть я чего-то не понимаю, но приведенную цитату, как мне кажется, следует читать строго наоборот: "в логе есть готовая таблица updated". Наличие before и after images - это по-Вашему не "готовая таблица"?

Вопрос мог бы вызвать следующий аспект - а понимаются ли здесь под images полные наборы данных или только измененные фрагменты? Но если учесть, что эти данные успешно попадают в inserted-deleted - видимо, полные; я прав?


Давайте попробуем вместо "понимания цитаты" посмотреть, что есть на самом деле. К сожалению, физическая структура лога закрыта от "конечного пользователя". И посмотреть, "что у него внутри" представляется возможным только с помощью недокументированных возможностей. Сделаем следующее, взяв любую бд с FULL RECOVERY MODEL.

USE temp
GO
BACKUP LOG temp WITH TRUNCATE_ONLY
GO

CREATE TABLE Table1(col1 int, col2 datetime)
GO

INSERT Table1 VALUES(1, GETDATE())
GO

UPDATE Table1 SET col1 = 2 , col2 = GETDATE() WHERE col1 = 1
GO

UPDATE Table1 SET col1 = 3 WHERE col1 = 2
GO

DELETE Table1 WHERE col1 = 3
GO

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

Теперь, воспользовавшись недокументированными возможностями, посмотрим, какие следы в логе оставил приведенный выше скрипт.

DBCC TRACEON (3604)
GO

DBCC LOG (temp, 3)--второй параметр, равный 3 - вывод очень подробной информации

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

Вставка:

Current LSN            Operation                 Context                   Transaction ID Tag Bits Log Record Length Previous LSN           Flag Bits Object Name                                                                                                                                                                                                                                                      Index Name                                                                                                                                    Page ID       Slot ID Previous Page LSN      Num Elements Element Element Length Offset Row Data                                                                                                                                                                                                                                                           Description                                                                                                                                                                                                                                                     
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001a6:0002 LOP_INSERT_ROWS LCX_HEAP 0000:000000fa 0x0000 76 00000006:000001a6:0001 0x1200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001a5:0002 1 0 19 0 0x1000100001000000A2568E006F990000020000

(1 row(s) affected)

Обновление 1:

Current LSN            Operation                 Context                   Transaction ID Tag Bits Log Record Length Previous LSN           Flag Bits Object Name                                                                                                                                                                                                                                                      Index Name                                                                                                                                    Page ID       Slot ID Previous Page LSN      Offset in Row Num Elements Element Element Length Offset Row Data                                                                                                                                                                                                                                                           Description                                                                                                                                                                                                                                                     
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001a7:0002 LOP_MODIFY_ROW LCX_HEAP 0000:000000fb 0x0000 76 00000006:000001a7:0001 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001a6:0002 4 2 0 5 0 0x01000000A2
00000006:000001a7:0002 LOP_MODIFY_ROW LCX_HEAP 0000:000000fb 0x0000 76 00000006:000001a7:0001 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001a6:0002 4 2 1 5 0 0x02000000A7

(2 row(s) affected)

Обновление 2:

Current LSN            Operation                 Context                   Transaction ID Tag Bits Log Record Length Previous LSN           Flag Bits Object Name                                                                                                                                                                                                                                                      Index Name                                                                                                                                    Page ID       Slot ID Previous Page LSN      Offset in Row Num Elements Element Element Length Offset Row Data                                                                                                                                                                                                                                                           Description                                                                                                                                                                                                                                                     
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001a8:0002 LOP_MODIFY_ROW LCX_HEAP 0000:000000fc 0x0000 68 00000006:000001a8:0001 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001a7:0002 4 2 0 1 0 0x02
00000006:000001a8:0002 LOP_MODIFY_ROW LCX_HEAP 0000:000000fc 0x0000 68 00000006:000001a8:0001 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001a7:0002 4 2 1 1 0 0x03

(2 row(s) affected)

Удаление:

Current LSN            Operation                 Context                   Transaction ID Tag Bits Log Record Length Previous LSN           Flag Bits Object Name                                                                                                                                                                                                                                                      Index Name                                                                                                                                    Page ID       Slot ID Previous Page LSN      Num Elements Element Element Length Offset Row Data                                                                                                                                                                                                                                                           Description                                                                                                                                                                                                                                                     
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001a9:0002 LOP_DELETE_ROWS LCX_HEAP 0000:000000fd 0x0000 76 00000006:000001a9:0001 0x1200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001a8:0002 1 0 19 0 0x1000100003000000A7568E006F990000020000

(1 row(s) affected)

Что мы видим.
1. Операции вставки и удаления имеют по 1му элементу в каждой "записи" лога и полную информацию о строке.
2. Операция обновления содержит 2 элемента. Причем в ней фиксируются только реально измененые данные, с указанием смешения от начала строки.

На мой взгляд, говорить о наличии готовой таблицы updated не совсем корректно. Впрочем, как и получение таблиц inserted и deleted из записи лога с типом операции LOP_MODIFY_ROW является не совсем тривиальной задачей.

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


На мой вгляд и объем выделяемой памяти и прочие затраты для реализации таблицы updated будут больше, хотя бы потому, что она должна содержать в два раза больше полей, чем inserted и deleted. В добавок ко всему, придется джоинить двойные записи в логе для операции update.

softwarer
Кто Вам сказал такую глупость? Не обращается разработчик к таблице - не будет никто строить таблицу. Или MSSQL неленив и сканирует лог вне зависимости от того, упоминаются ли в триггере inserted/deleted или нет?


С чего Вы взяли, что это глупость?! У Вас есть неопровержимые доказательства обратного? Зачем серверу тратить дополнительные ресурсы на произвольный доступ к логу (который предназначен впревую очередь для последовательной записи в конец) вне зависимости от того, идет обращение к таблицам inserted и deleted в тригере или нет?! Именно сканирование лога всегда, в независимости используются эти таблицы или нет, я бы назвал глупостью.

softwarer
Вернее, наоборот. И разработчик тратит силы, чтобы написать джойн, и сервер тратит ресурсы на то, чтобы его сделать.


Не совсем так. Сервер тратит ресурсы на обращение (с произвольным доступом) к логу, только если разработчик напишет этот самый джоин.

softwarer
Кстати, позволю себе такой вопрос. Если делается inserted inner join deleted - сервер сделает один проход по логу или два?


Судить об этом можно, на мой вгляд, только по косвенным показателям. Таким, как план выполнения.

Если сравнить пропорции разделения ресурсов между запросами в баче (сам запрос + запрос в триггере) для следующего скрипта:

CREATE TABLE Table1(col1 INT NOT NULL, col2 datetime NOT NULL)
GO

INSERT Table1 VALUES(1, GETDATE())
INSERT Table1 VALUES(2, GETDATE())
INSERT Table1 VALUES(3, GETDATE())
INSERT Table1 VALUES(4, GETDATE())
INSERT Table1 VALUES(5, GETDATE())
GO


UPDATE 
  Table1
SET
  col2 = GETDATE()
WHERE
  col1 = 3
GO

CREATE TRIGGER ut_Table1 ON Table1
FOR UPDATE
AS
  SELECT
    *
  FROM
    inserted i
    INNER JOIN deleted d ON
    i.col1 = d.col1
GO
UPDATE 
  Table1
SET
  col2 = GETDATE()
WHERE
  col1 = 3
GO

ALTER TRIGGER ut_Table1 ON Table1
FOR UPDATE
AS
  SELECT
    *
  FROM
    inserted i
GO
UPDATE 
  Table1
SET
  col2 = GETDATE()
WHERE
  col1 = 3
GO

ALTER TRIGGER ut_Table1 ON Table1
FOR UPDATE
AS
  SELECT
    *
  FROM
    deleted d
GO
UPDATE 
  Table1
SET
  col2 = GETDATE()
WHERE
  col1 = 3
GO

ALTER TRIGGER ut_Table1 ON Table1
FOR UPDATE
AS
  SELECT
    *
  FROM
    Table1
GO
UPDATE 
  Table1
SET
  col2 = GETDATE()
WHERE
  col1 = 3
GO

DROP TABLE Table1

То update, где в триггере джоинятся inserted и deleted разобъется в пропорции 67%/33% UPDATE/SELECT в тригере. Где идет просто обращение к inserted или deleted в пропорции 80%/20%. И, соответственно в плане выполения первого будут присутствовать операторы Inserted Scan и Deleted Scan (объединенные Nesteed Loops), во втором случаи, только Inserted Scan или Deleted Scan.

softwarer
Эта информация была бы очень интересна, но к сожалению, Вы ее как раз и не показали. Просто сказали: "в отношение updated этого не скажешь". В последующем обсуждении, вплоть до первых абзацев этого поста, мы как раз и развиваем ту попытку показать.


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

На все остальное, касательное MS SQL vs Oracle и "кто первым начал" отвечать нет ни времени, ни желания.
18 июл 07, 09:21    [4401650]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

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


Если не у Вас это займёт не больше пары минут, не могли бы ли Вы повторить update для нескольких строчек?

Т.е. показательно как сгруппированы записи, парами или группами deleted/inserted.
18 июл 07, 09:55    [4401805]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Для такого скрипта:

INSERT Table1 VALUES(1, GETDATE())
INSERT Table1 VALUES(1, GETDATE())
INSERT Table1 VALUES(1, GETDATE())
INSERT Table1 VALUES(2, GETDATE())
INSERT Table1 VALUES(2, GETDATE())
INSERT Table1 VALUES(2, GETDATE())

GO

UPDATE Table1 SET col2 = GETDATE() WHERE col1 = 1
GO

В логе будет:

Current LSN            Operation                 Context                   Transaction ID Tag Bits Log Record Length Previous LSN           Flag Bits Object Name                                                                                                                                                                                                                                                      Index Name                                                                                                                                    Page ID       Slot ID Previous Page LSN      Offset in Row Num Elements Element Element Length Offset Row Data                                                                                                                                                                                                                                                           Description                                                                                                                                                                                                                                                     
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001b0:0002 LOP_MODIFY_ROW LCX_HEAP 0000:00000104 0x0000 68 00000006:000001b0:0001 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001af:0002 8 2 0 2 0 0xA5B9
00000006:000001b0:0002 LOP_MODIFY_ROW LCX_HEAP 0000:00000104 0x0000 68 00000006:000001b0:0001 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 0 00000006:000001af:0002 8 2 1 2 0 0xE8BC

(2 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits Object Name Index Name Page ID Slot ID Previous Page LSN Offset in Row Num Elements Element Element Length Offset Row Data Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001b0:0003 LOP_MODIFY_ROW LCX_HEAP 0000:00000104 0x0000 68 00000006:000001b0:0002 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 1 00000006:000001b0:0002 8 2 0 2 0 0xA5B9
00000006:000001b0:0003 LOP_MODIFY_ROW LCX_HEAP 0000:00000104 0x0000 68 00000006:000001b0:0002 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 1 00000006:000001b0:0002 8 2 1 2 0 0xE8BC

(2 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits Object Name Index Name Page ID Slot ID Previous Page LSN Offset in Row Num Elements Element Element Length Offset Row Data Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001b0:0004 LOP_MODIFY_ROW LCX_HEAP 0000:00000104 0x0000 68 00000006:000001b0:0003 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 2 00000006:000001b0:0003 8 2 0 2 0 0xA5B9
00000006:000001b0:0004 LOP_MODIFY_ROW LCX_HEAP 0000:00000104 0x0000 68 00000006:000001b0:0003 0x0200 dbo.Table1 (405576483) Table1 (0) 0001:00000022 2 00000006:000001b0:0003 8 2 1 2 0 0xE8BC

(2 row(s) affected)

Т.е. в данном случаи сервер использует Inplace Update. Сгенерим ситуацию, которая заставит сервер выполнить Deffered Update (насколько я понял, именно это Вас интересовало):

CREATE TABLE tbTest (id int primary key, test varchar(20))
GO

INSERT INTO tbTest VALUES (1, 'Test string')
GO

UPDATE tbTest SET id = id + 1
GO

DBCC log (temp, 3)
GO


В результат, опустив лишнии детали получим:

Current LSN            Operation                 Context                   Transaction ID Tag Bits Log Record Length Previous LSN           Flag Bits Server UID  UID         SPID        Beginlog Status Begin Time              Transaction Name     Description                                                                                                                                                                                                                                                     
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ----------- ----------- ----------- --------------- ----------------------- -------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001bc:0001 LOP_BEGIN_XACT LCX_NULL 0000:0000010a 0x0000 60 00000000:00000000:0000 0x0200 0 -1 51 0x01000000 2007/07/18 10:11:04:333 D M L DML

(1 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits Object Name Index Name Page ID Slot ID Previous Page LSN Num Elements Element Element Length Offset Row Data Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001bc:0002 LOP_DELETE_ROWS LCX_MARK_AS_GHOST 0000:0000010a 0x0000 84 00000006:000001bc:0001 0x1200 dbo.tbTest (421576540) (0) 0001:00000029 0 00000006:000001bb:0001 1 0 26 0 0x300008000100000002000001001A005465737420737472696E67

(1 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits Object Name Index Name Page ID Slot ID Previous Page LSN Rowbits First Bit Rowbits Bit Count Rowbits Bit Value Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ----------------- ----------------- ----------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001bc:0003 LOP_SET_BITS LCX_PFS 0000:00000000 0x0000 56 00000000:00000000:0000 0x0000 dbo.tbTest (421576540) (0) 0001:00000001 0 00000006:000001b8:0009 363 1 0x01

(1 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits Object Name Index Name Page ID Slot ID Previous Page LSN Num Elements Element Element Length Offset Row Data Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ------------ ------- -------------- ------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001bc:0004 LOP_INSERT_ROWS LCX_CLUSTERED 0000:0000010a 0x0000 84 00000006:000001bc:0002 0x1200 dbo.tbTest (421576540) (0) 0001:00000029 1 00000006:000001bc:0002 1 0 26 0 0x300008000200000002000001001A005465737420737472696E67

(1 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits Object Name Index Name Page ID Slot ID Previous Page LSN Data Pages Delta Reserved Pages Delta Used Pages Delta Data Rows Delta Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------------- ------------- ------- ---------------------- ---------------- -------------------- ---------------- --------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001bc:0005 LOP_DELTA_SYSIND LCX_CLUSTERED 0000:0000010a 0x0000 80 00000006:000001bc:0004 0x0200 dbo.sysindexes (2) (0) 0001:00000018 33 00000006:000001bb:0002 0 0 0 0

(1 row(s) affected)

Current LSN Operation Context Transaction ID Tag Bits Log Record Length Previous LSN Flag Bits End Time Transaction Begin Replicated Records Oldest Active LSN Server Name Database Name Mark Name Description
---------------------- ------------------------- ------------------------- -------------- -------- ----------------- ---------------------- --------- ----------------------- ---------------------- ------------------ ---------------------- ---------------------------------------------------------------- ---------------------------------------------------------------- ---------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
00000006:000001bc:0006 LOP_COMMIT_XACT LCX_NULL 0000:0000010a 0x0000 52 00000006:000001bc:0001 0x0200 2007/07/18 10:11:04:333 00000006:000001bc:0001 1119306776 none none none

(1 row(s) affected)
18 июл 07, 10:17    [4401959]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

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


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

Т.е. идея "создавать updated из "соседних" записей" в общем случае не проходит.
18 июл 07, 10:33    [4402056]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
Я продолжаю надеятся, уже совсем слабо, что вы поймёте, что описаное вами выше - "снизу вверх"

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




softwarer
Ее выходом является поток семантик - директив, имеющих смысл фраз, таких как "определи переменную", "возьми элемент массива", "присвой переменной значение выражения" итп



Поток, ИМХО, это последовательность независимых элементов, которая поступает на приёмник частями, более того, в это время на источнике поток может продолжать формироваться.

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

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

Оба вышеуказанных подхода в моём понимании - "сверху вниз"

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

Третий подход в моём понимании - "снизу вверх"

Я достаточно подробно объяснил свою мысль?





18 июл 07, 11:34    [4402488]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
pkarklin

Прежде всего, спасибо за столь тщательный и подробный ответ.

pkarklin
2. Операция обновления содержит 2 элемента. Причем в ней фиксируются только реально измененые данные, с указанием смешения от начала строки.

Что ж, как и должно быть. Я обратил внимание на этот аспект в основном из-за Вашей фразы про inserted/deleted "они и есть лог".

pkarklin
На мой взгляд, говорить о наличии готовой таблицы updated не совсем корректно. Впрочем, как и получение таблиц inserted и deleted из записи лога с типом операции LOP_MODIFY_ROW является не совсем тривиальной задачей.

Безусловно. Собственно, основа моего удивления - то, что операции в любом случае эквивалентны по прямым затратам.

pkarklin
На мой вгляд и объем выделяемой памяти и прочие затраты для реализации таблицы updated будут больше, хотя бы потому, что она должна содержать в два раза больше полей, чем inserted и deleted.

"Чем inserted и deleted поотдельности". Но столько же, сколько они вместе взятые. Грубо говоря, для выполнения запроса

select * from updated

надо будет вытянуть, разместить и обработать ровно столько же информации, сколько и для выполнения запроса

select * from inserted join deleted

pkarklin
В добавок ко всему, придется джоинить двойные записи в логе для операции update.

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

pkarklin
softwarer
Кто Вам сказал такую глупость? Не обращается разработчик к таблице - не будет никто строить таблицу. Или MSSQL неленив и сканирует лог вне зависимости от того, упоминаются ли в триггере inserted/deleted или нет?

С чего Вы взяли, что это глупость?!

С чего бы ни взял, ниже Вы сами высказались ровно на ту же тему: "....Именно сканирование лога всегда, в независимости используются эти таблицы или нет, я бы назвал глупостью". Раз уж мы с Вами согласны по этому поводу, может обосновывать не требуется?

А вот с чего Вы сначала постулируете некую работу даже если результаты не потребуются - словами "Согласитесь, что просканить записи лога, прочитав только старые данные и только новые данные по затратам это не тоже самое, что сделать джоин после скана. Причем без какой-либо гарантии, что результаты этого джоина (таблица updated) реально потребуются." - а потом ровно это же называете глупостью, я, признаться, не понимаю.

pkarklin
Не совсем так. Сервер тратит ресурсы на обращение (с произвольным доступом) к логу, только если разработчик напишет этот самый джоин.

Угу. Итого, имеем: в N% ситуций разработчик пишет join либо обращается к updated. В 100-N% никаких ресурсов никто не тратит. Итого во втором случае равенство, в первом - все равно кроме дополнительного join-а.

pkarklin
softwarer
Кстати, позволю себе такой вопрос. Если делается inserted inner join deleted - сервер сделает один проход по логу или два?

.....
То update, где в триггере джоинятся inserted и deleted разобъется в пропорции 67%/33% UPDATE/SELECT в тригере. Где идет просто обращение к inserted или deleted в пропорции 80%/20%.

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

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

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

drev
Т.е. идея "создавать updated из "соседних" записей" в общем случае не проходит.

Отчего же? Алгоритм может быть чуть сложнее, чем "взять данные как они лежат", но в любом случае линковать их можно и нужно. Даже если они лежат в формате "сначала все удаления, потом все вставки", сформировать результат здесь - чем-то типа sort join - все равно будет много эффективнее, нежели сканить лог дважды.
18 июл 07, 12:36    [4403052]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
"Чем inserted и deleted поотдельности". Но столько же, сколько они вместе взятые. Грубо говоря, для выполнения запроса


select * from updated

надо будет вытянуть, разместить и обработать ровно столько же информации, сколько и для выполнения запроса


select * from inserted join deleted


Представьте себе, что в тексте одного триггера есть упоминание inserted, deleted и предлагаемой Вами updated, а в другом - только updated.

В этом случае придется имплементировать два механизма для получения updated. В случае join мы с такой проблемой не столкнёмся.
18 июл 07, 12:48    [4403156]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

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

softwarer wrote:
> Трактуйте ее как хотите. Я могу рассказать, что это было - тест на
> внимательность, который я собирался использовать, если беседа с locky
> пойдет по одному из возможных вариантов. Детали, пардон, уже не вспомню.
Не надо меня "проверять на внимательность" :)
Лучше - ответье прямо: Вы всё еще уверены, что изменения Оракла можно
будет провести за 2 часа + неделя тестирования?
Учитывая то, что мы уже куда более двух часов "обсасываем" только
некоторые "теоретические основы" подобного рода изменения, а к практикие
или хотя бы к общему знаменателю (хоть какому то) так и не пришли.

Posted via ActualForum NNTP Server 1.4

18 июл 07, 12:54    [4403199]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

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

softwarer wrote:
> Во, началось. Прямо хоть в очередной раз посылай Вас на мой сайт читать
> про логику.
Сорри, не удержусь :)

"Мои труды читать надо!" (С) Проф. Выбегалло, Понедельник начинается в
субботу

:)

Posted via ActualForum NNTP Server 1.4

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

Откуда:
Сообщений: 9365
drev
В этом случае придется имплементировать два механизма для получения updated.


с чего бы ???
18 июл 07, 13:43    [4403698]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
Gluk (Kazan)
drev
В этом случае придется имплементировать два механизма для получения updated.


с чего бы ???


первый - лога (by softwarer)

второй - из уже вычитанных inserted, deleted
18 июл 07, 13:52    [4403802]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
drev
Gluk (Kazan)
drev
В этом случае придется имплементировать два механизма для получения updated.


с чего бы ???


первый - лога (by softwarer)

второй - из уже вычитанных inserted, deleted


достаточно только первого. зачем делать ЛИШНЮЮ работу ???
18 июл 07, 13:54    [4403824]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить