Използването на тригери тук просто изисква проблеми.
Освен това изборът на използване на планировчика вероятно не е най-добрата идея, тъй като планираните задания могат да виждат само ангажирани данни. Така че или се ангажирате в тригера, който изхвърля логиката на транзакцията извън прозореца, или промените в таблиците се забавят до края на транзакцията.
Трябва или да:
-
Използвайте процедури. Най-простият отговор. Когато имате множество приложения, те не трябва да изпълняват DML/businees логика директно, те винаги трябва да го правят с процедури, така че всички да изпълняват един и същ код. Забранете директния DML с безвъзмездни средства или изгледи. Може да се наложи да принудите използването на процедури чрез
INSTEAD OFзадейства върху изгледи (имайте предвид това само ако не можете да модифицирате приложението). -
Вероятно дори по-добре от процедурите във вашия случай:използвайте схема, която не съдържа дублирани данни. Не искате да съхранявате излишни данни:това прави разработката на приложения по-сложна от необходимото. По отношение на производителност, ресурси и енергия, най-добрият начин да разрешите проблем е, когато осъзнаете, че задачата е ненужна.
От описанието на вашия модел ето колоните, които можете да премахнете:
- task.duration_in_days
- task.end_date
- task.needs_recomputation
- подзадача.начална_дата
- подзадача.крайна_дата
taskтаблицата ще съдържа само началната дата и всяка подзадача ще съхранява само своята продължителност. Когато имате нужда от обобщената информация, използвайте съединения. Можете да използвате изгледи, за да позволите на приложенията да имат прозрачен достъп до данните. -
Използвайте заобиколно решение на мутиращия тригер който използва пакетни променливи за идентифициране на модифицирани редове с
BEFOREиAFTERизявление задейства. Очевидно това ще включва много код, който ще бъде труден за кодиране, тестване и поддръжка, така че трябва да използвате опции (1) и (2), когато е възможно вместо това.
