INSERT / UPDATE / DELETE 용 단일 트리거가있는 것이 좋습니다.

Question

하나의 테이블에서 다른 테이블로 삽입 / 업데이트 / 삭제 작업을 미러링해야합니다. 예를 들어 TableA에 삽입하려면 TableB에 복사하고 TableB에 적용된 TableA로 업데이트하고 TableA에서 TableB에 적용됩니다. TableB가 일정한 값을위한 추가 열이 1 개의 추가 열이 있으므로 매우 간단한 트리거가 필요합니다.

3 개의 분리 된 트리거를 쓰거나 모든 작업을 수행하는 트리거가 하나의 트리거가 있는지 확실하지 않습니다.

이것은 Sybase ASE, MSSQL 및 Oracle의 3 개의 데이터베이스에 대한 것입니다. 솔루션을 유사하게 유지하고 싶습니다 (따라서 모든 데이터베이스 또는 모든 모든 데이터베이스 1에 대해 1 중 하나).

는 3 개의 트리거 대 1을 갖는 것이 바람직하다. 또는 해결책의 실제 이점이 있거나

Answer 1

Assuming that you actually need a trigger and that table B cannot simply be defined as a view on top of table A or that table B cannot just be defined with a foreign key that references a row in A along with the constant, that A cannot be redefined to add the additional column (potentially with a default value of the constant), one trigger at least lets you keep all the related logic in one place rather than having multiple places that need to be updated when you do something like add a new column to A. But I would be extremely wary of any architecture that involved having two different tables reflecting essentially the same data in both. That violates normalization, it adds to the system's I/O workload, and it makes the whole system more complex.

Answer 2

There's no efficiency to be gained by separating the triggers, other than the loss of efficiency of the trigger execution itself, when trying to determine what the action on Table A was.

IE 3 separate triggers can employ no validation logic to determine what just occurred on Table A, since the trigger being fired itself can behave in a bubble because it knows since it's firing, it was due to single action.

Whereas a 3-in-1 trigger, you must check the status of the virtual deleted and inserted tables and derive the action each and every time it's fired.

If you're not worried about the (admittedly small) performance impact of deriving the "action", or maybe don't even need to know in Table B the "action" that just occurred on Aable A...then I think 1 is perfectly fine.