|
|
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
я делал через промежуточную таблицу, но может возможно както реализовать логику. при изменении записи в таблице, нужно чтобы сработал тригер и обновил другую запись в этой же таблице... я делал через промежуточные 2. тригер обновления - делает вставку в промежуточную2(заявка на обновление другой записи) из промежуточной2, переносим всё в промежуточную1, из промежуточной1 все удаляем, срабатывает тригер удаления, и вот он сделает в начальной нужные изменения. если опустить промежуточную2, у меня всеравно ругаеться на тригер удаления из промежуточной1, который сделает апдейт в таблице, который запустит тригер, который сделает вставку в промежуточную1... может я что не верно делаю??? ЗЫ таблица содержит дерево , - сылки на родителя у каждой записи. и вот есть изменения, которые должны каскадно ити по дереву к верхнему родителю(агрегация) или к потомкам всем (каскадное изменение свойства). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2014, 15:43:02 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
alex564657498765453при изменении записи в таблице, нужно чтобы сработал тригер и обновил другую запись в этой же таблице...Это потенциально порождает зацикливание. Полагаю, наиболее разумно - выполнять изменения не запросом, а хранимой процедурой. Централизует логику и снимает проблемы при использовании триггеров. да и побыстрее будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2014, 18:21:20 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Akinaalex564657498765453при изменении записи в таблице, нужно чтобы сработал тригер и обновил другую запись в этой же таблице...Это потенциально порождает зацикливание. Полагаю, наиболее разумно - выполнять изменения не запросом, а хранимой процедурой. Централизует логику и снимает проблемы при использовании триггеров. да и побыстрее будет. постой. тут есть два момента 1)возможно мы друг друга не поняли, но в таблице дерево! и эти изменения это - агрегация значения - от потомка вверх до корня везде надо учесть изменение - каскадное обновление ветки = узлу некоторому поставили атрибут хиден, значит вся ветка должна получить этот атрибут. 2)сдесь есть ещо и оптимизация. наверно лучше кодом показать как счас.(возьмём агрегацию) Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. вот я и збегаю цикла, а главное при нагрузке у меня за секунду возникает несколько сотен событий в подчинённой таблице(сдесь не указана) приводящих к изменению одного из узлов(поле тотал), но мы не меняем размер несколько сотен раз ибо тригер на подчинёной таблице вставку делает в changes аналогично - при дубле ключа обновляет. и того, получая 300 дочерних елементов за секунду, получаем одну запись в changes, где пре-агрегированы все 300 изменений. паралельно в другие узлы братья нашему, идёт аналогично вставка 300 дочерних но дед будет скорей всего обновляться один раз, благодаря томуже механизму преагрегации. changes, tchanges -- ENGINE MEMORY =========== кстате пока писал, набрёл на мысль... наверно в ивенте, надо бы загнать в транкзанкцию перенос данных и очистку tchanges... а то ведь можем лишнее удалить...верно я мыслю? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Акина, верно ли сработает код последний??? что не смогут ничего вставить в таблицу ведь я всю её трогаю... или надо както подругому залочить всю таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2014, 11:52:44 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
ВНИМАНИЕ!!! я опустил строчки в тригерах, которые делают проверку - являеться ли корнем данный узел. если являеться, то понятно дело что у него родителя уже нету и заявки никакой делать не надо на изменение поля тотал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2014, 11:54:16 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
alex5646574987654531)возможно мы друг друга не поняли, но в таблице дерево! и эти изменения это - агрегация значения - от потомка вверх до корня везде надо учесть изменение - каскадное обновление ветки = узлу некоторому поставили атрибут хиден, значит вся ветка должна получить этот атрибут. Я тебя понял. Ты меня - нет. В процедуре ты можещь организовывать любой перебор, который тебе потребен. Хоть перебор вверх по дереву, хоть вниз, хоть в обе стороны по два с половиной раза. Даже метод перебора не сильно важен - хоть частные запросы с использованием промежуточных переменных, хоть курсоры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2014, 09:04:21 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Akinaalex5646574987654531)возможно мы друг друга не поняли, но в таблице дерево! и эти изменения это - агрегация значения - от потомка вверх до корня везде надо учесть изменение - каскадное обновление ветки = узлу некоторому поставили атрибут хиден, значит вся ветка должна получить этот атрибут. Я тебя понял. Ты меня - нет. В процедуре ты можещь организовывать любой перебор, который тебе потребен. Хоть перебор вверх по дереву, хоть вниз, хоть в обе стороны по два с половиной раза. Даже метод перебора не сильно важен - хоть частные запросы с использованием промежуточных переменных, хоть курсоры. тогда я тебя тоже понял, но не имея масивов проблематично будет .....вверх ещо ладно, а вот вниз..... ладно, а что скажешь по поводу очистки таблицы tchanges. я же могу удалить записи, которые небыли перенесены, но были вставлены в последние милисикунды перед очисткой таблицы.... что тогда делать лучше.... вешать lock table write ?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2014, 11:18:58 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
alex564657498765453но не имея масивовКурсора вполне достаточно - у тебя же дерево, а не сетка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2014, 23:25:45 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Akinaalex564657498765453но не имея масивовКурсора вполне достаточно - у тебя же дерево, а не сетка. плин...я уже потерял нить рассуждений?? вопрос ещо остаёться, как быстро и точно, из одной таблицы скинуть данные в другую удалив их в первой? тригер повесить на удаление и удалять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 12:01:42 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
alex564657498765453как быстро и точно, из одной таблицы скинуть данные в другую удалив их в первой? тригер повесить на удаление и удалять? Код: sql 1. 2. И забудь слово "триггер" ввобще! рано тебе о них думать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 13:02:24 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Akinaalex564657498765453но не имея масивовКурсора вполне достаточно - у тебя же дерево, а не сетка. а нащот курсора и дерева не понял как это вяжеться..... вот есть у меня дерево, 10 000 000 узлов, глибина дерева от 4 до 400 ... какието елементы изменили своё значение, разные уровни, разные изменения... по каким критериям идти курсором!? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 13:19:19 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Akinaalex564657498765453как быстро и точно, из одной таблицы скинуть данные в другую удалив их в первой? тригер повесить на удаление и удалять? Код: sql 1. 2. И забудь слово "триггер" ввобще! рано тебе о них думать. мдя ...если так ити, то уже лучше просто повесить тригер и удалять всё под чистую, и оно само перенесёться в другую благодаря тригеру. ну то есть сдаёться мне быстрее будет, чем вот так... учитывая что так - так это обе таблицы лочаться, и все процесы которые хотели туда вставку делать притормозяться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 13:39:29 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
AkinaИ забудь слово "триггер" ввобще! рано тебе о них думать. тригеры, это то с чего начинаеться работа с базой :) всмысле после создания таблиц, перед тем как чтото выбирать, надо чтото вставить, а раз вставить данные, значит и контроль бизнеслогики. мы ж не лохи, чтобы учить язык програмирования, а базы данных как какта ляжет :) даже не догадываться что есть слова - тригер , представление, хранимая процедура, события. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 13:42:54 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
alex564657498765453мдя ...если так ити, то уже лучше просто повесить тригер и удалять всё под чистую, и оно само перенесёться в другую благодаря тригеру. Во-первых, триггер срабатывает на каждую запись. То есть пакетное выполнение записи в архив превращается в пачку дискретных запросов. Во-вторых, триггер срабатывает вовсе даже не на любое удаление. Это некоторые гражданы умеют не вспомнить вовремя, а потом удивляются, куда это делись записи... В третьих, триггеры требуют отдельного сопровождения, которое вовсе не самое удобное. Есть ещё куча резонов, почему триггеры - это одно из последних средств при решении задач такого рода. alex564657498765453тригеры, это то с чего начинаеться работа с базойНи в коем случае!!! alex564657498765453перед тем как чтото выбирать, надо чтото вставить, а раз вставить данные, значит и контроль бизнеслогики. Да не вопрос. Пиши необходимые пользовательские процедуры и реализуй в них любую потребную тебе логику. Какие сложности? Но сперва продумай структуру БД. Если у тебя сложное дерево и его обслуживание - почему оно хранится не в nested set? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 16:08:33 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Akinaalex564657498765453мдя ...если так ити, то уже лучше просто повесить тригер и удалять всё под чистую, и оно само перенесёться в другую благодаря тригеру. Во-первых, триггер срабатывает на каждую запись. То есть пакетное выполнение записи в архив превращается в пачку дискретных запросов. Во-вторых, триггер срабатывает вовсе даже не на любое удаление. Это некоторые гражданы умеют не вспомнить вовремя, а потом удивляются, куда это делись записи... В третьих, триггеры требуют отдельного сопровождения, которое вовсе не самое удобное. Есть ещё куча резонов, почему триггеры - это одно из последних средств при решении задач такого рода. alex564657498765453тригеры, это то с чего начинаеться работа с базойНи в коем случае!!! alex564657498765453перед тем как чтото выбирать, надо чтото вставить, а раз вставить данные, значит и контроль бизнеслогики. Да не вопрос. Пиши необходимые пользовательские процедуры и реализуй в них любую потребную тебе логику. Какие сложности? Но сперва продумай структуру БД. Если у тебя сложное дерево и его обслуживание - почему оно хранится не в nested set? а зачем мне нестид сетс? чтобы вместо обновления цепочки до родителя - пускай даже 100 селектов и 100 апдейтов делать 5 000 000 апдейт? нестид сетс это понт, который при маленьких базах помагает избежать рекурсии. на больших обьём ...можно конечно оптимизировать, ставить буферы номеров на узлы, но для таких деревьев, где любой узел может когда угодно, и как угодно разростись в глубину, это тоже будет гемор не малый... ==== нащот тригеров. изучение баз данных в вузах, создание структуры, тригеры .... дальше :) тут один человек с опытом работы с оракл, говорит что не факт что каскадное удаление ветки дерева(как у меня счас) будет быстрее работать в системе, чем самому сделать по принципу удаление елемента - дочерние елементы родител=нулл. в цикле ищем по 1000 скажем елементов без родителя и удаляем их. чем каскадные действия... как бы про память тоже надо думать, и про нехватку её и сброс данных временых на винчестер. и про то что другие в процесе в базе происходят, которым тоже важно чтоб памяти имено оперативки хватало. я тоже стороник того, что фоновый процес должен работать с минимум ресурсов, с как можно короткими локами данных - что б не мешал основным процесам. ну будет родитель не 2 а 10 секунд ждать пока по цепочке до него дойдёт информация о увеличении размера, ибо в 50 колене добавился елемент, не страшно. страшно если 10 секунд будет ждать клиент, пока вставка выполниться нового узла, изза того что лок висит на таблице, и не может отработь тригер или неважно что, но то что должно родителю выставить новый размер. ========== Акина. вариант с вставкой данных и удалением по джоину, из старой я понял, я и так его расматривал первым. я ищу другие варианты, чтоб протестировать быстродейтсвие разных. вот и спрашиваю, как вариант с транкейтом правильно организовать ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 17:04:24 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
Я не понял - ты зачем Оракл приплетаешь? Там всё не так, как в MySQL... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2014, 22:42:28 |
|
||
|
trigger table11_update_after with update table11 ...
|
|||
|---|---|---|---|
|
#18+
AkinaЯ не понял - ты зачем Оракл приплетаешь? Там всё не так, как в MySQL... сори, я кратко выразился, изза этого трудно понять мысль было. исправляю - большинство без протекции среди моих друзей-знакомых, с базой сталкиваються сначала с мусклом на работе, ктото после вуза может попасть сразу в банк и будет мсскл, ктото с постгри, и только после опыта год-два на таких субд, реально попасть в контору на норм зп с оракал(без опыта с самой оракл) поэтому в нашем кружке програмистов - работа с оракл, это как символ опыта с разными субд и не малым. вот последнее я и имел ввиду. он сказал(чувак этот), что он затрудняеться сказать точно, ибо давно работал с мусклом. но он бы не был так категоричен в утверждении, что каскадное удаление дерева, быстрее чем тригерами потихоньку удалять. сокрей всего в мускле именно не удастаться получить прирост скорости на тригреррах, но как минимум скорей всего скорость субд будет тойже, а вот локов больших не будет...а это полезно, если в удаляемой огромной ветке, некоторые узлы находяться на обработке других процесов, и вот они не затормозяться... да гдето другие сделают работу в холостую, обработают узел, который будет всеравно удалён, но это лучше чем другой процес в лок упрёться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.06.2014, 12:10:04 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38675368&tid=1834622]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
48ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 196ms |
| total: | 306ms |

| 0 / 0 |
