|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Коллеги, пожалуйста, подскажите как в потрахах 2.5.8 будет формироваться версия записи, если из одного и того же триггера обновляемого представления и в одной и той же транзакции делать UPDATE не сразу всех полей одним оператором, а последовательно. К примеру, сначала UPDATE первичного ключа, если его OLD и NEW не совпадают, а затем всех прочих полей по тому же принципу (естественно, с условием, учитывающим изменение первичного ключа, если таковое имело место). В базу ляжет одна версия записи с измененными полями, или же на каждый UPDATE будет формироваться своя запись? Еще вопрос - кроме сравнения OLD и NEW есть еще какой-нибудь функционал контроля из триггера изменения полей, как это, к примеру, сделано в MS SQL? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 11:45 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
rdb_dev, первый (в рамках одной тр-ции) апдейт обычно создаёт бекверсию как дельту от новой первичной записи. Второй апдейт той же записи создаст новую бекверсию, но уже не как дельту а как полную запись. Потом удалит бекверсию, созданную на предыдущем шаге, и почистит индексы. Все последующие апдейты будут работать по этой же схеме. Т.е. на диске в любом случае будет одна бекверсия. Но вот затраты на чистку индексов могут быть велики, особенно если там уже есть длинная цепочка более старых бекверсий. Поэтому я крайне не рекомендую делать 100500 апдейтов одной записи там, где этого можно избежать. Битовой маски изменённых полей нет. Нужно явно сравнивать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 11:51 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
hvlad, спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 11:52 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
rdb_devК примеру, сначала UPDATE первичного ключа, если его OLD и NEW не совпадают, а затем всех прочих полей по тому же принципу (естественно, с условием, учитывающим изменение первичного ключа, если таковое имело место).Хоть убей - не вижу, зачем тут множество апдейтов, а не один. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 11:54 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
hvlad, я уже понял, что овчинка выделки не стоит и лучше сразу делать UPDATE всех 100500 полей, даже если в обновляемом представлении было изменено только одно поле. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 11:59 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
rdb_dev, Что это у вас там за вьюха в которой надо ПК базовой таблицы менять? Я бы побоялся такой код делать ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 12:15 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
rdb_dev, Запись меняется по одинаковым правилам, хоть одно поле, хоть 100500. Не на чем тут сэкономить, включая в апдейт только конкретные. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 12:22 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Симонов Денисrdb_dev, Что это у вас там за вьюха в которой надо ПК базовой таблицы менять? Я бы побоялся такой код делатьХитрый составной legacy ключ, включающий в себя как часть первичный ключ мастер-таблицы. Не я это придумал, если что... :) До меня были умельцы. Весь зоопарк софта под причёсанную и нормализованную базу никто, естественно, не будет, потому и приседаю с представлениями, чтобы сохранить прослойку наследия. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:13 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
07.11.2018 13:13, rdb_dev пишет: > Хитрый составной legacy ключ, включающий в себя как часть первичный ключ мастер-таблицы. Не я это придумал, если что... :) PRIMARY KEY не должны быть составными. никогда. переделай его на UNIQUE KEY - избежишь приседаний с притопами и прихлопами. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:19 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Мимопроходящий, ты именно мне хочешь это объяснить? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:22 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Мимопроходящий, если я правильно понял он делает рефакторинг в своей системе. Меняет одну большую таблицу (с уродливыми ключом) на несколько поменьше, а для совместимости вьюху городит. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:25 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Симонов Денис, в общих чертах так. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:27 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Мимопроходящийпеределай его на UNIQUE KEY - избежишь приседаний с притопами и прихлопами. Взамен получишь новый геморрой с нарушением ключа на ровном месте. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:29 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
07.11.2018 13:29, Dimitry Sibiryakov пишет: > Взамен получишь новый геморрой с нарушением ключа на ровном месте. креститься надо. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:31 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
rdb_devв общих чертах так. Тогда откуда у тебя вообще там составной ключ вылез? На вьюхах ключей не бывает. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:33 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, он у него был на старой таблице. А вот теперь он хитрым образом хочет эмулировать эту таблицу вьюхой на основе нескольких таблиц с простыми ключами. Но геморрой будет ещё тот. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:38 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovrdb_devв общих чертах так. Тогда откуда у тебя вообще там составной ключ вылез? На вьюхах ключей не бывает. Зато бывает на таблицах, которые надо заменить вьюхами с полным сохранением функционала. Сначала хотел сделать ПК из нескольких полей и собирать их только для вьюхи, но проблема в том, что каскад таблиц на шесть уровней и на предпоследнем уровне скомпонованный по определенным правилам ключ, который в оригинале, ко всему прочему, был еще и текстовым, занимал несколько десятков символов. Городить таблицы мапинга UUID в legacy, а при формировании вьюхи тащить это всё, тоже приятного мало. Мне удалось этот длиннющий ключ определенным образом впихнуть в INT64, благо правила формирования ключа позволили. В общем, долгая история... ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 13:49 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Симонов ДенисА вот теперь он хитрым образом хочет эмулировать эту таблицу вьюхой на основе нескольких таблиц с простыми ключами. Но геморрой будет ещё тот. Причём отрастил его он себе сам. rdb_devЗато бывает на таблицах, которые надо заменить вьюхами с полным сохранением функционала. При такой замене ключ обычно отсыхает, превращаясь в простой, даже не уникальный, индекс. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 14:00 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovПри такой замене ключ обычно отсыхает, превращаясь в простой, даже не уникальный, индекс. не факт. Ограничение уникальности иногда может быть требованием бизнес логики. Или у тебя какая-то особая неприязнь к UNIQUE KEY? Ну можно индекс уникальный сделать, если FK по нему не делать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 14:09 |
|
Последовательный update полей таблицы из триггера обновляемого представления
|
|||
---|---|---|---|
#18+
Симонов ДенисИли у тебя какая-то особая неприязнь к UNIQUE KEY? Да. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2018, 14:18 |
|
|
start [/forum/topic.php?fid=40&msg=39729284&tid=1560917]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
160ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 301ms |
total: | 559ms |
0 / 0 |