Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Привет! Возможно ли в MySQL написать тригер так, чтобы мне внутри не отдельные строки изменения перебирать (FOR EACH ROW), а получить доступ сразу ко всему набору измененных строк? Это чтобы избежать итераций. Что-то вроде (внутри тригера): Код: plsql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 13:36 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Yuri Abele, вроде как синтаксис создания триггера подразумевает обязательное FOR EACH ROW. то есть он в любом случае будет выполняться для каждой измененной строки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 13:48 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
мы же говорим о строках, а не о полях? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 13:51 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Darkripple, о строках. Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 14:48 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Darkrippleсинтаксис создания триггера подразумевает обязательное FOR EACH ROW. то есть он в любом случае будет выполняться для каждой измененной строки Хреново! Еще один аргумент миграровать на что-то другое. Например MSSQL: MSSQL-Books-OnlineThe deleted and inserted tables hold the old values or new values of the rows that may be changed by the user action. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 14:56 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Yuri AbeleХреново! Еще один аргумент миграровать на что-то другое. а в чём собственно проблема обрабатывать построчно? ну кроме того, что один апдейт десяти записей выполнится быстрее десятка апдейтов по одной. каких таких итераций вы собираетесь избежать? MSSQL-Books-OnlineThe deleted and inserted tables hold the old values or new values of the rows that may be changed by the user action. а кроме MSSQL-я кто-то еще так умеет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 15:13 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Так если в таблице изменится 100 строк, и эти изменения должны как-то отобразиться на другую таблицу, то придется другую таблицу 100 раз UPDATEить, вместо одного UPDATE-with-JOIN (см. в первом постинге) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 15:18 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Darkrippleа кроме MSSQL-я кто-то еще так умеет? ORACLE может и так и так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 15:22 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Yuri AbeleORACLE может и так и так если не ошибаюсь, в оракле таких встроенных возможностей нет. можно сделать свой костыль типа создания временных таблиц (аналогов inserted и deleted), заполнять их в триггере for each row, а потом в триггере after statement массово обрабатывать (ну или использовать один compound триггер, но только начиная с 11g). но вот работать сразу с пакетом измененных записей - не получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 15:40 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Darkrippleесли не ошибаюсь, в оракле таких встроенных возможностей нет. Погуглил - да, похоже на то. Очень жаль - это очень оптимизирует работу тригеров при многострочных изменениях. Я их (тригеры) вообще не люблю - плохой это стиль - но тут пришлось и очень удивился, что в MySQL только построчно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 16:12 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Yuri Abeleесли в таблице изменится 100 строк, и эти изменения должны как-то отобразиться на другую таблицу, то придется другую таблицу 100 раз UPDATEить Во-первых, это означает плохой дизайн БД. Во-вторых, 100 update по одной записи не обязаны быть медленнее одного update с join. Если делать ставки, я бы как раз поставил на обратное: что update join будет медленнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2017, 13:59 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Т.е. один пробег по таблице будет медленнее чем 100? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 08:54 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Yuri AbeleТ.е. один пробег по таблице будет медленнее чем 100? join подразумевает как минимум две таблицы. И таки да, 100 индексных обращений к одной таблице скорее всего будут быстрее, чем пробег по одной таблице и 100 индексных обращений к другой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 13:29 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Мы про тригер говорили. И речь шла о блочном или итеративном изменения блока строк. В последнем одних только скаканий из контекста в контекст сколько наберётся. P.S. На счет плохого дизайна я сам выше сказал, но увы, в данном случае оное уже построено. Я страшнее расскажу - они в тригерах агрегаты по другим таблицам считают. С одной стороны за раз (в случае аграгаций) одна строка только меняется, но такие изменения происходят гораздо чаще, чем потом чтение этих аграгатов. Вот и сидит пользователь и недоумевает, почему изменение одной простой цифорки нужно так долго сохранять ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 18:30 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Yuri AbeleЯ их (тригеры) вообще не люблю - плохой это стиль - но тут пришлось и очень удивился, что в MySQL только построчно.в триггерах и их применении ничего плохого нет, это отличный инструмент для разнообразных целей. иначе бы их не придумывали и не вводили бы. главное знать, что они существуют и учитывать их. а уж какую часть логики заложить в триггеры, а какую вынести наружу - решает архитектор, сообразно целям-задачам и своему опыту (ну и возможностям СУБД само собой). триггеры в mysql появились относительно недавно, возможно он просто еще "не дорос" до пакетных триггеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:19 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Darkrippleв триггерах и их применении ничего плохого нет, это отличный инструмент для разнообразных целей.Триггер - это костыль. Костыль, позволяющий "втащить" итеративную обработку в групповую. А костыль - это всегда плохо. Штатная возможность выполнения смежных действий сразу над всем массивом - это вынесение логики на сервер с реализацией в формате хранимых процедур. Но ленивые языковые программисты не хотят программировать сразу в двух точках и изучать все возможности того, что используют - им проще оставаться в рамках одной среды и использовать костыли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:25 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
AkinaТриггер - это костыль. Костыль, позволяющий "втащить" итеративную обработку в групповую. А костыль - это всегда плохо. костыль - плохо. но с чего вдруг триггер является костылём? у человека куча встроенных триггеров в виде врождённых и приобретенных рефлексов - это разве плохо? зачем переводить дыхание, сердцебиение, выработку гормонов на уровень осознаваемых/контролируемых действий? зачем мне выносить, например, фиксацию момента времени вставки/изменения записи во внешний механизм, и потом следить еще чтобы использовался каждый раз только этот механизм? Почему я должен доверять AkinaНо ленивые языковые программисты не хотят программировать сразу в двух точках и изучать все возможности того, что используют - им проще оставаться в рамках одной среды и использовать костыли.а если этих точек не две, а 5-10? а если часть этих точек не подвластна настройке/доработке? триггер как раз и является одной из "возможностей того, что используют" - это возможность СУБД среагировать на изменение в таблице, запустить какие-либо механизмы, независимо от пути попадания записи в таблицу или радивости/нерадивости разработчика внешнего механизма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 09:55 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
не дописал про "Почему я должен доверять "... хотел упомянуть внешних по отношению к БД разработчиков, которые минуют "хранимые процедуры", но по сути это организационный момент. конечно это моё сугубое ИМХО, но правильный триггер в правильном месте - это не только не зло, но и добро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 10:05 |
|
||
|
TRIGGER не с FOR EACH ROW, а для всего change set
|
|||
|---|---|---|---|
|
#18+
Для меня триггеры всегда были сродни какому-то скрытому и плохо конролируемому функционалу. Особенно, если их можно несколько на одно и то же действие подвесить - последовательность выполнения негарантируема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.06.2017, 23:15 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39476810&tid=1830580]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
56ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 12ms |
| total: | 164ms |

| 0 / 0 |
