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

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


с чего бы ???


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

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


достаточно только первого. зачем делать ЛИШНЮЮ работу ???


потому, что второе во многих случаях будет быстрее. В 99,99%, ИМХО. Причём, мы говорим даже не об одном порядке.
18 июл 07, 13:59    [4403872]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
locky
Лучше - ответье прямо: Вы всё еще уверены, что изменения Оракла можно
будет провести за 2 часа + неделя тестирования?

Я все еще уверен, что просчитанное мной изначально изменение можно провести за два часа плюс неделя тестирования. В него не входит реализация фич, отсутствующих в MSSQL, как-то updated, selected....

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

То, что малоосмысленная болтовня легко займет сколь угодно много времени, для меня очевидно и без текущего примера. Сейчас идет в миниатюре тот процесс "митингов и прочего", который расписывал drev и который ни на шаг не продвинет в сторону реализации. Я, как мне кажется, сразу говорил, что оцениваю затраты на "сделать", а не пустые телодвижения по этому поводу.
18 июл 07, 14:11    [4404004]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
drev
первый - лога (by softwarer)
второй - из уже вычитанных inserted, deleted

Глупость, простите, причем несерьезная. Хотя бы потому, что предлагаемый мной механизм предполагает отсутствие в inserted и deleted строк, относящихся к update, и конструировать их будет физически не из чего.

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

Ну а если Вы привыкли к таким вот усложнениям - неудивительно, что на простейшую фичу отводите два года работы.
18 июл 07, 14:22    [4404108]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

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

softwarer wrote:
> Я все еще уверен, что просчитанное мной изначально изменение можно
> провести за два часа плюс неделя тестирования. В него не входит
> реализация фич, отсутствующих в MSSQL, как-то updated, selected....
Блажен, кто верует - но это проблема верующего :)
И вообще - чего ж Вы прицепились тогда к updated - если в мс его нет и
"делать" Вы его "не собирались"?

> То, что малоосмысленная болтовня легко займет сколь угодно много
> времени, для меня очевидно и без текущего примера. Сейчас идет в
> миниатюре тот процесс "митингов и прочего", который расписывал drev и
> который ни на шаг не продвинет в сторону реализации. Я, как мне кажется,
> сразу говорил, что оцениваю затраты на "сделать", а не пустые
> телодвижения по этому поводу.
А если еще посчитать только общее время, затраченное на нажимание
кнопок, или - что куда кошернее - время, в течении которого были
задействованы (находились в замкнутом состоянии) кнопки - то время можно
сократить до 5-10 минут и менее.
Вы ведь вроде не теоретик, а практик?
И что - правда, что у Вас принято что-либо делать без согласования с
другими рабочими группами, без анализа зависимостей, без спеков?

Posted via ActualForum NNTP Server 1.4

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

Откуда: 127.0.0.1
Сообщений: 67463
Блог
drev
Я достаточно подробно объяснил свою мысль?

Надеюсь, этого хватит, хотя пока не уверен.

Мне кажется, я увидел в Вашем ответе пару факторов, определяющих наше взаимонепонимание, но предпочту взять паузу перед ответом, по двум причинам. Мне кажется, я смогу написать ответ, который внесет ясность, но во-первых, перед этим стоит не спеша еще раз обдумать сказанное Вами, а во-вторых, такой ответ получится довольно затратным по времени, и писать его с работы будет не совсем этично.
18 июл 07, 14:33    [4404198]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
первый - лога (by softwarer)
второй - из уже вычитанных inserted, deleted

Глупость, простите, причем несерьезная. Хотя бы потому, что предлагаемый мной механизм предполагает отсутствие в inserted и deleted строк, относящихся к update, и конструировать их будет физически не из чего.

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

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


Это уже становится интересным:)

А если мне, как в большинстве случаев, нужны только данные из inserted?:)

Вы понимаете, что в Вашей модели придётся делать разные механизмы работы с логом?:)

Далее, Вы мне не ответили на "снизу вверх" :(

Да, Александр, меня зовут Игорь
18 июл 07, 14:35    [4404221]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
locky
И что - правда, что у Вас принято что-либо делать без согласования с
другими рабочими группами, без анализа зависимостей, без спеков?

"У меня" принято тратить на принятие решений время, адекватное сложности задачи. Утрируя - я не буду писать спецификации, анализировать зависимости и согласовывать с другими рабочими группами, желая поправить опечатку в форме ввода данных.
18 июл 07, 14:36    [4404223]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
Я достаточно подробно объяснил свою мысль?

Надеюсь, этого хватит, хотя пока не уверен.

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


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

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


с чего бы ???


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

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


достаточно только первого. зачем делать ЛИШНЮЮ работу ???


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


Нет не будет (IMHO) потому что все три псевдотаблицы можно строить вместе.
И как справедливо отметил softwarer у сервера больше шансов выполнить эту работу оптимально чем у пользователя в триггере (join то не обычный )
18 июл 07, 14:47    [4404317]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

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

softwarer wrote:
> "У меня" принято тратить на принятие решений время, адекватное сложности
> задачи. Утрируя - я не буду писать спецификации, анализировать
> зависимости и согласовывать с другими рабочими группами, желая поправить
> опечатку в форме ввода данных.
ну, если уж так утрировать - то мы вполне вероятно получим программный
продукт, у которого реализация расходится с документацией ;)

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

Posted via ActualForum NNTP Server 1.4

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

Откуда: 127.0.0.1
Сообщений: 67463
Блог
drev
Это уже становится интересным:)
А если мне, как в большинстве случаев, нужны только данные из inserted?:)

Это в триггере на update? С трудом, признаться, представляю такое большинство случаев. Однако, я не зря говорил про "только те таблицы, которые понадобятся".

drev
Вы понимаете, что в Вашей модели придётся делать разные механизмы работы с логом?:)

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

drev
Далее, Вы мне не ответили на "снизу вверх" :(

Уже ответил. Кроме того, если обратите внимание, Вам на формирование ответа потребовалось порядка двадцати часов; я ничуть не возражаю, но как мне кажется, тоже имею право на паузу.

drev
Да, Александр, меня зовут Игорь

Что ж, будем знакомы. Пока не уверен, что "очень приятно", но во всяком случае, "интересно" ;-)
18 июл 07, 14:57    [4404409]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

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


с чего бы ???


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

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


достаточно только первого. зачем делать ЛИШНЮЮ работу ???


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


Нет не будет (IMHO) потому что все три псевдотаблицы можно строить вместе.
И как справедливо отметил softwarer у сервера больше шансов выполнить эту работу оптимально чем у пользователя в триггере (join то не обычный )


softwarer, Вы видите, что судя по упоминанию трех таблиц одновременно, Вашу модель не понял не только я?

Да хоть десять раз одновременно.

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

И зачем формировать все три, если например updated будет внутри if?:) Чтоб сервер ненужной работой загрузить?:)
18 июл 07, 15:01    [4404442]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
softwarer
drev
Вы понимаете, что в Вашей модели придётся делать разные механизмы работы с логом?:)

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

Стоп, виноват; вероятно я неверно понял эту Вашу фразу. Уточните, пожалуйста, что за "разные механизмы" Вы имеете в виду?
18 июл 07, 15:02    [4404450]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

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

Пока суть да дело....

softwarer, а зачем, собссно, updated вдобавок к inserted\deleted?

вроде как тот же орацл прекрасно обходится new\old - и не чихает при
этом. это во первых.
во вторых - каким образом предпоалагается реализация?
в виде некой псевдотаблицы с колонками было\стало?
нечто вроде
updated
old_name
new_name
old_id
new_id

и т.д.?

Posted via ActualForum NNTP Server 1.4

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

Откуда: 127.0.0.1
Сообщений: 67463
Блог
drev
softwarer, Вы видите, что судя по упоминанию трех таблиц одновременно, Вашу модель не понял не только я?

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

drev
После того, как у нас две уже доступны процессу третью читать не надо.

Игорь, могу напомнить еще раз: данные в предлагаемый мной таблицах не пересекаются. Ваше "не надо" относится к варианту inserted/deleted в их текущей реализации, при которой updated - некоторая денормализация над ними. Я же предлагаю помещать вставленные записи (image after) - в inserted, удаленные записи (image before) - в deleted, а измененные (images before & after as old and new) - в updated.

drev
И зачем формировать все три, если например updated будет внутри if?:) Чтоб сервер ненужной работой загрузить?:)

А кто сказал "формировать все три, если например..."? Напишете анализатор, который правильно обработает этот случай - замечательно. Затруднитесь - все равно, это лучше, нежели дважды сканировать лог (как происходит сейчас).

Тут, кстати, есть еще один момент, не уверен, что упоминал его раньше. Вы неявно предполагаете, что "удержать таблицу в памяти для последующих обращений" - оптимальнее, нежели повторно читать лог. Я склонен к тому же мнению, но не то чтобы абсолютно в этом уверен; это уже надо считать, и не на пальцах. Разумеется, я имею в виду не оптимальность для одной сессии, а оптимальность для сервера в целом.
18 июл 07, 15:10    [4404526]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
locky
Пока суть да дело....

softwarer, а зачем, собссно,

Извините, но я не хочу отвечать на вопросы, рассмотренные на двух-трех предыдущих страницах. Не столько даже потому, что жалко, сколько потому, что наверняка кто-нибудь не удержится ответить на что-нибудь, с чем тогда был не совсем согласен, но промолчал, и в итоге, те же самые три страницы раскрутятся по новой.
18 июл 07, 15:12    [4404543]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
locky
Member

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

softwarer wrote:
> Извините, но я не хочу отвечать на вопросы, рассмотренные на двух-трех
> предыдущих страницах. Не столько даже потому, что жалко, сколько потому,
ок, будем считать - для полноты картины нужен updated - хотя мне не до
конца понятно - задлянафига, но весчь, наверное, нужная.

Сойдемся на том - что таки да, нужно.
Имплементация, я так понимаю - в виде таблицы вышеприведенной структуры?

Posted via ActualForum NNTP Server 1.4

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

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

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

Стоп, виноват; вероятно я неверно понял эту Вашу фразу. Уточните, пожалуйста, что за "разные механизмы" Вы имеете в виду?


Два случая:

1. в запросе используются только поля "new" из updated.
2. И new, и old

По уму сервер должен выбирать разные данные из лога, так?

Далее, более интересный вопрос. У меня триггер на insert, update.

В традиционном варианте, я обращаюсь к таблице inserted в обоих случаях.

Вы пишите : "предлагаемый мной механизм предполагает отсутствие в inserted и deleted строк, относящихся к update, и конструировать их будет физически не из чего."

Что делать??
18 июл 07, 15:20    [4404609]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Это в триггере на update? С трудом, признаться, представляю такое большинство случаев. Однако, я не зря говорил про "только те таблицы, которые понадобятся".


Александр. Позволю себе напомнить, что происходит внутри триггера FOR UPDATE.

1. Записи с новыми значениями полей находятся в таблице inserted и базовой таблице триггера.
2. Записи с старыми значениями полей находятся в таблице deleted.

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

Достаточно сджоинить базовую таблицу с deleted. Таким образом можно вообще исключить ситуацию inserted JOIN deleted в триггере на UPDATE.
18 июл 07, 15:28    [4404686]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
drev
1. в запросе используются только поля "new" из updated.

Признаться, я считаю этот вариант совершенно теоретическим. Даже если нас не интересует дельта (то есть ситуация не похожа, например, на изменение остатков, где мы считаем new-old), нас интересует сам факт изменения (new != old). Cкажем, такой пример как денормализация; у нас изменилась запись, и нужно поле из нее записать в дочерние записи. Если мы при этом не проверим "поле действительно изменило значение", мы просто сделаем тупую лишнюю работу по поиску и модификации N записей в то же значение.

drev
По уму сервер должен выбирать разные данные из лога, так?

Однако, согласитесь, это ничуть не мешает работать по написанной схеме. Анализатору всего лишь нужно проверить, какие поля реально используются в триггере, и не пихать в updated неиспользуемых (обратите внимание - я усилил поставленную Вами задачу; мы проверяем уже не только old/new, а каждое поле в отдельности. Кстати, не удивлюсь, если это имеет смысл; скажем, глупо лезть в таблицу за недостающими данными (которые не менялись и потому отсутствуют в логе), если они не понадобятся в триггере.

Само собой, это соображение равно верно и для сегодняшней реализации inserted/deleted (кстати, если есть под рукой тестовая база, было бы интересно проверить. Запустить тест, подобный тесту Павла, потом такой же, но с добавленной в таблицу большой необновляемой колонкой, и проследить, как изменится время и объем ввод-вывода).

drev
Далее, более интересный вопрос. У меня триггер на insert, update. В традиционном варианте, я обращаюсь к таблице inserted в обоих случаях. Что делать??

Скажем, inserted union all updated. Мне кажется, я еще в самом начале писал, что выбор между "почти всегда писать inserted join updated" и "крайне редко писать inserted union all updated".
18 июл 07, 15:36    [4404782]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
pkarklin
Таким образом для того, когда в запросе необходимы и старые и новые значения совсем не обязательно джоинить inserted и deleted - то, с чего собственно все и началось. Достаточно сджоинить базовую таблицу с deleted.

Согласен, можно, но не понимаю, чем это лучше.

Давайте оставим в стороне вопрос "при update-е нужны только old или только new" - если есть комментарии по этому поводу, давайте обсуждать их там, где вопрос поднят Игорем, будет больше порядка. Здесь давайте рассмотрим вопрос "нужны таки и те, и те данные".

Напомню, "начиналось все" не столько с обязательности джойна, сколько с оптимальности выполнения операций в целом; "постоянно писать join" - несколько раздражает, но полагаю не особо сложно. У нас есть выбор между

- updated
- inserted join deleted
- basetable join deleted

Так вот, я вообще говоря предполагаю, что третий вариант в любом случае уступает второму (точнее - не превосходит). Почему: потому что если менялось мало данных, "сджойнить две виртуальных таблички в памяти" будет заведомо эффективнее, нежели делать поиск по большой базовой таблице (тоже в памяти, если не успеет вытесниться, но тем не менее - бегать по индексам итп). Если же данных менялось много - выбор будет между full scan-ом большой базовой таблицы с фильтрацией и проходом по меньшей по размеру inserted, и здесь при "удачном" объеме изменений (допустим, 20% от общего числа строк, неравномерно распределенных) разница в эффективности может быть колоссальной.
18 июл 07, 15:49    [4404897]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Признаться, я считаю этот вариант совершенно теоретическим. Даже если нас не интересует дельта (то есть ситуация не похожа, например, на изменение остатков, где мы считаем new-old), нас интересует сам факт изменения (new != old). Cкажем, такой пример как денормализация; у нас изменилась запись, и нужно поле из нее записать в дочерние записи. Если мы при этом не проверим "поле действительно изменило значение", мы просто сделаем тупую лишнюю работу по поиску и модификации N записей в то же значение.


CREATE TRIGGER ut_SomeTable
FOR UPDATE
AS
  UPDATE
    T
  SET
    SomeField = T1.Value - d.Value
  FROM
    AnotherTable T
    INNER JOIN SomeTable T1 ON
    T.ID = T1.ID
    INNER JOIN deleted d ON
    T1.ID = d.ID
WHERE
    T1.Value <> d.Value
18 июл 07, 15:51    [4404917]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
softwarer
Member

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

Если я правильно понял Ваш пример (триггер висит на SomeTable), то он в точности относится к предыдущему: Вы просто вместо inserted используете SomeTable. Это, кстати, расходится с примером Игоря (он говорит об использовании "только new" значений, Вы - "только old"). Но в любом случае мое "теоретически" относилось к "без join вообще"; что же до предлагаемой Вами замены - ответил выше.
18 июл 07, 15:56    [4404960]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
softwarer
drev
1. в запросе используются только поля "new" из updated.

Признаться, я считаю этот вариант совершенно теоретическим. Даже если нас не интересует дельта (то есть ситуация не похожа, например, на изменение остатков, где мы считаем new-old), нас интересует сам факт изменения (new != old). Cкажем, такой пример как денормализация; у нас изменилась запись, и нужно поле из нее записать в дочерние записи. Если мы при этом не проверим "поле действительно изменило значение", мы просто сделаем тупую лишнюю работу по поиску и модификации N записей в то же значение.

drev
По уму сервер должен выбирать разные данные из лога, так?

Однако, согласитесь, это ничуть не мешает работать по написанной схеме. Анализатору всего лишь нужно проверить, какие поля реально используются в триггере, и не пихать в updated неиспользуемых (обратите внимание - я усилил поставленную Вами задачу; мы проверяем уже не только old/new, а каждое поле в отдельности. Кстати, не удивлюсь, если это имеет смысл; скажем, глупо лезть в таблицу за недостающими данными (которые не менялись и потому отсутствуют в логе), если они не понадобятся в триггере.

Само собой, это соображение равно верно и для сегодняшней реализации inserted/deleted (кстати, если есть под рукой тестовая база, было бы интересно проверить. Запустить тест, подобный тесту Павла, потом такой же, но с добавленной в таблицу большой необновляемой колонкой, и проследить, как изменится время и объем ввод-вывода).

drev
Далее, более интересный вопрос. У меня триггер на insert, update. В традиционном варианте, я обращаюсь к таблице inserted в обоих случаях. Что делать??

Скажем, inserted union all updated. Мне кажется, я еще в самом начале писал, что выбор между "почти всегда писать inserted join updated" и "крайне редко писать inserted union all updated".


1. К сожалению, я не могу обсуждать с Вами детали реализации :( могу лишь сказать, что двойное чтение лога есть лишь предположение, а не факт, ок?

2. Union all? У Вас в любом из случаев в одной из таблиц будет ноль записей.

3. Вы существенно ошибаетесь в Ваших оценках. Я думаю, через мои руки прошло на пару порядков больше SQL Server кода , чем через Ваши, в силу специфики работы. Я оцениваю вероятность навскидку больше 50%.

4. Вам не кажется, что мы пришли к моменту, когда понятно, что тройка inserted, updated, deleted избыточна и, благодаря этому - противоречива?

T.e. достаточно либо пары inserted, deleted либо одной updated?
18 июл 07, 15:59    [4404997]     Ответить | Цитировать Сообщить модератору
 Re: Покритикуйте Оракл 10г  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
softwarer
Здесь давайте рассмотрим вопрос "нужны таки и те, и те данные".


Ок. Предыдущий мой пост со скриптом триггера можно засчитывать в обсуждение этого вопроса.

softwarer
У нас есть выбор между

- updated
- inserted join deleted
- basetable join deleted

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


Что в первом, что во втором случаи джоин не является самоцелью. Будет еще как миниум один джоин для выполнения необходимых действий с другой таблицей и, возможно, дополнительное условие фильтрации. Трудно (без проведения тестирования) сказать, что будет эффективнее - формирование двух таблиц (inserted и deleted) или джоин по второму варианту, с учетом того, что раз записи попали под обработку то необходимые страницы данных и индексов уже закешированы. Т.е. практически надо сравнивать, что будет быстрее - проход по логу, для формирования inserted и Index Seek по базовой таблице.

softwarer
Если же данных менялось много - выбор будет между full scan-ом большой базовой таблицы с фильтрацией и проходом по меньшей по размеру inserted, и здесь при "удачном" объеме изменений (допустим, 20% от общего числа строк, неравномерно распределенных) разница в эффективности может быть колоссальной.


Возможно что в этом случаи выигрыш и будет, но о колласальности его можно будет говорить только проведя тестирование.
18 июл 07, 16:04    [4405045]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 24   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить