데이터베이스 트리거가 악의입니까? [닫은]

데이터베이스 트리거가 나쁜 생각입니까?

내 경험상 그들은 놀라운 부작용을 일으킬 수 있고 디버그하기가 어렵 기 때문에 (특히 트리거가 다른 트리거를 일으킬 때) 악합니다. 종종 개발자는 트리거가 있는지를 생각조차하지 않습니다.

반면에 FOO데이터베이스에 새 데이터 가 생성 될 때마다 발생해야하는 논리가 있는 경우 가장 확실한 위치는 FOO 테이블의 삽입 트리거입니다.

트리거를 사용하는 유일한 시간은 설정과 같은 간단한 것 ModifiedDate입니다.

트리거의 주요 문제는

• 그들은 완전히 전역 적입니다-그들은 테이블 활동의 맥락에 상관없이 적용됩니다.
• 그들은 몰래입니다. 그들이 의도하지 않은 (그리고 매우 신비한) 결과로 당신을 다치게 할 때까지 그들이 있다는 것을 잊기 쉽습니다.

이는 적절한 상황에서주의해서 사용해야한다는 의미입니다. 내 경험상 관계 적 무결성 문제로 제한되는 경우가 있습니다 (때로는 선언적으로 얻을 수있는 것보다 세밀한 부분이있는 경우도 있음). 일반적으로 비즈니스 또는 거래 목적이 아닙니다. YMMV.

아니요, 그들은 실제로 좋은 생각입니다. 특정 트리거에 문제가있는 경우 올바르게 수행하지 않지만 일반적 으로 트리거 자체의 개념이 아니라 구현에 문제가 있음을 의미 합니다 :-).

DBMS 관련 활동이 속한 데이터베이스의 제어하에 배치되므로 트리거를 많이 사용합니다. DBMS 사용자는 이런 종류의 것들에 대해 걱정할 필요가 없습니다. 데이터의 무결성은 데이터베이스 를 사용하는 응용 프로그램이나 사용자가 아니라 데이터베이스 자체에 있습니다. 데이터베이스에 제약 조건과 트리거 및 기타 기능이 없으면 규칙을 적용하는 응용 프로그램이 남게되며 데이터를 파괴하는 데는 한 명의 불량 또는 버그가있는 응용 프로그램 / 사용자 만 있으면됩니다.

예를 들어 트리거가 없으면 자동 생성 열과 같은 놀라운 기능이 존재하지 않으므로 열을 선택할 때 각 행에서 함수를 처리해야합니다. DBMS 성능을 저하시킬 가능성이 높으며 삽입 / 업데이트 시간에 자동 생성 열을 만드는 것이 훨씬 낫습니다.

또한 트리거가 부족하면 열이 특정 형식을 갖도록 사전 트리거와 같은 DBMS에서 데이터 규칙이 적용되지 않습니다. 이것은 일반적으로 외래 키 조회 인 데이터 무결성 규칙과 다릅니다.

도구는 결코 악하지 않습니다. 이러한 도구를 사용하는 것은 악할 수 있습니다.

나는 동의한다. 방아쇠의 문제는 방아쇠가 아닌 사람입니다. 코더가 올바르게 검사하는 것에 대해 더 많은 것을 고려하고 고려하는 것이 더 많지만 삶을 단순화하기 위해 색인을 버리지 않습니다. (잘못된 인덱스는 잘못된 트리거만큼 나빠질 수 있습니다)

내 생각에 트리거의 중요성은 다음과 같습니다
.-모든 시스템은 항상
유효한 상태 여야합니다.-이 유효한 상태를 시행하기위한 코드는 중앙 집중식이어야합니다 (모든 SP에 기록되지는 않음)

유지 관리 관점에서 트리거는 더 많은 주니어 / 아마추어 코더에 대한 경쟁 코더 및 문제에 매우 유용합니다. 그러나이 사람들은 어떻게 든 배우고 성장해야합니다.

나는 그것이 당신의 작업 환경에 달려 있다고 생각합니다. 잘 배우고 체계적으로 신뢰할 수있는 믿을만한 사람들이 있습니까? 그렇지 않은 경우 두 가지 선택 사항이있는 것 같습니다
.-보상을 위해 기능을 잃어야
한다는 점에 동의합니다.-다른 사람이 필요하거나 더 나은 교육 및 관리가 필요하다는 점에 동의합니다.

그들은 가혹하게 들린다. 그러나 그것은 기본적 진실입니다.

트리거는 악할뿐만 아니라 올바른 데이터베이스 디자인에 필요하다고 생각합니다. 응용 프로그램 프로그래머는 데이터베이스가 응용 프로그램의 영향을받는 것으로 생각합니다. 그들은 종종 틀립니다. 데이터 변경의 출처에 관계없이 데이터 무결성을 유지하려면 트리거가 필요하며 일부 프로그래머는 소중한 응용 프로그램 이외의 다른 것이 영향을 줄 수 있다고 생각하기에 너무 민족적이기 때문에이를 피하는 것은 어리석은 일입니다. 유능한 데이터베이스 개발자 인 경우 트리거를 디자인하거나 테스트하거나 문제를 해결하는 것은 어렵지 않습니다. 또한 트리거가 (나처럼) 발생하면 트리거가 예기치 않은 결과를 초래한다고 판단하기가 어렵습니다. 내 sp에서 참조하지 않는 테이블에 FK 오류가 있다는 오류가 발생하면, 나는 트리거가 문제를 일으키는 원인이 무엇인지 생각하지 않고 유능한 데이터베이스 개발자도 마찬가지라는 것을 알고 있습니다. 비즈니스 규칙을 응용 프로그램에만 사용하는 것은 다른 사람들이 규칙이 존재하고 프로세스에서 위반한다는 사실을 모르기 때문에 잘못된 데이터를 발견 한 가장 큰 원인입니다. 데이터 중심 규칙은 데이터베이스에 속하며 트리거는보다 복잡한 규칙을 시행하는 데 중요합니다.

대부분 그렇습니다.

방아쇠로 어려움을 겪는다는 것은 "당신의 등 뒤로"일을한다는 것입니다. 응용 프로그램을 유지 관리하는 개발자는 응용 프로그램을 쉽게 인식하지 못하고 눈치 채지 않고도 문제를 해결하는 변경 작업을 수행 할 수 없었습니다.

유지 관리 작업을 추가하는 복잡한 계층을 만듭니다.

저장 프로 시저 / 루틴은 트리거를 사용하는 대신 일반적으로 동일한 작업을 수행 할 수 있지만 명확하고 유지 관리 가능한 방식으로 저장 루틴을 호출하면 개발자가 소스 코드를보고 정확히 무슨 일이 발생하는지 확인할 수 있습니다.

트리거는 매우 강력하고 유용하며 트리거가 문제에 대한 최상의 솔루션 인 시나리오는 여러 가지가 있습니다.

그들은 또한 아주 좋은 "해킹"도구입니다. 코드와 데이터베이스를 모두 즉시 제어 할 수없는 상황이 종종 있습니다. 코드의 다음 주요 릴리스에 대해 2 개월을 기다려야하지만 데이터베이스에 즉시 패치를 적용 할 수 있으면 테이블에 트리거를 추가하여 일부 추가 기능을 수행 할 수 있습니다. 그런 다음 코드 릴리스가 가능하면 원하는 경우이 트리거를 동일한 기능의 코딩 된 버전으로 바꿀 수 있습니다.

하루가 끝나면 무엇을하고 있는지 모른다면 모든 것이 "악"입니다. 방아쇠를 결정하는 것은 그것을 이해하지 못하는 개발자가 있기 때문에 일부 사람들은 운전할 수 없기 때문에 자동차가 악하다고 주장하는 것과 같습니다 ...

트리거는 용도가 있습니다. 로깅 / 감사 및 "최종 수정 날짜"유지는 이전 응답에서 언급 한 두 가지 매우 유용한 용도입니다.

그러나 좋은 디자인의 핵심 원칙 중 하나는 비즈니스 규칙 / 비즈니스 로직 / 원하는 것이 무엇이든 한 곳에 집중해야한다는 것입니다. 일부 로직 (트리거 또는 저장된 프로 시저를 통해)을 데이터베이스에 배치하고 애플리케이션의 일부는 해당 원칙을 위반합니다. 두 곳에서 논리를 복제하는 것은 서로 동기화되지 않기 때문에 더욱 악화됩니다.

이미 언급 된 "최소한의 놀라움의 원칙"문제도 있습니다.

트리거는 올바르게 사용하면 좋은 도구입니다. 감사 변경, 요약 테이블 채우기 등과 같은 것들을 위해 특별히

이제 다른 트리거를 시작하는 하나의 트리거로 "트리거 지옥"으로 끝나는 경우 "악"일 수 있습니다. 나는 한때 그들이 "플렉스 트리거"라고 불리는 것을 가지고있는 COTS 제품에서 일했다. 이 트리거는 동적 SQL 스팅 이 실행될 때마다 컴파일 될 때 테이블에 저장되었습니다 . 컴파일 된 트리거는 조회를 수행하고 해당 테이블에 실행할 플렉스 트리거가 있는지 확인한 다음 "flex"트리거를 컴파일하고 실행합니다. 이론적으로 이것은 제품이 쉽게 사용자 정의 되었기 때문에 실제로 멋진 아이디어처럼 들렸지 만 실제로는 모든 컴파일로 인해 데이터베이스가 거의 폭발했습니다 ...

그래, 당신이하고있는 일을 관점에서 유지한다면 그들은 훌륭합니다. 감사, 요약, 자동 시퀀싱 등과 같이 매우 간단한 것이라면 문제가 없습니다. 테이블의 성장률과 트리거가 성능에 미치는 영향을 명심하십시오.

높은 수준에서는 트리거에 대한 두 가지 사용 사례가 있습니다 1

1) 물건을 "자동적으로"만드는 것. 이 경우 트리거는 부작용을 유발하며, 실행 된 (기본) 연산자 삽입, 업데이트 또는 삭제를 고려하여 예상치 않은 방식으로 데이터를 변경하여 트리거를 발생시킵니다.

여기서 일반적인 합의는 방아쇠가 실제로 해롭다는 것입니다. INSERT, UPDATE 또는 DELETE 문의 잘 알려진 의미를 변경하기 때문입니다. 이 세 가지 기본 SQL 연산자의 의미를 변경하면 나중에 나중에 SQL 기본 형식으로 조작 할 때 더 이상 예상 된 방식으로 작동하지 않는 데이터베이스 테이블에서 작업해야하는 다른 개발자를 물리 칠 수 있습니다.

2) 우리가 선언적으로 다룰 수있는 데이터 무결성 규칙을 적용하기 위해 (CHECK, PRIMARY KEY, UNIQUE KEY 및 FOREIGN KEY 사용). 이 사용 사례에서 모든 트리거는 QUERY (SELECT) 데이터로 INSERT / UPDATE / DELETE에 의한 변경이 허용되는지 확인합니다. 선언적 제약이 우리에게하는 것처럼. 이 경우에만 우리 (개발자)가 시행을 프로그래밍했습니다.

후자의 유스 케이스에 트리거를 사용하는 것은 해롭지 않습니다.

http://harmfultriggers.blogspot.com 에서 블로깅하고 있습니다 .

필자는 트리거를 원하는 기능을 달성하는 가장 직접적인 방법으로 사용하지 않는 개발자와 절대 사용하지 않을 개발자를 항상 사용해야한다는 것을 알고 있습니다. 두 캠프 사이의 교리와 거의 같습니다.

그러나 나는 개인적으로 MarkR에 완전히 동의합니다. 더 눈에 띄고 유지하기 쉬운 트리거와 기능적으로 동등한 코드를 거의 (거의) 작성할 수 있습니다.

악하지 않다. 그들은 실제로 같은 것을 단순화합니다

1. 레코드 또는 데이터베이스 스키마에 대한 변경 사항의 로깅 / 감사

프로덕션 환경에서 변경 사항을 롤백하는 ALTER TABLE에 대한 트리거가있을 수 있습니다. 우발적 인 테이블 수정을 방지해야합니다.

2. 복수의 데이터베이스에서 참조 불완전 성 (1 차 / 외국 키 관계 등) 강화

아냐, 그들은 악하지 않다-그들은 단지 오해되고있다 : -D

트리거는 유효하게 사용되지만 레트로 해킹으로 너무 자주 사용되어 결과를 악화시킵니다.

응용 프로그램의 일부로 DB를 개발하는 경우 논리는 항상 코드 또는 호출하는 코드에 있어야합니다. 트리거는 나중에 디버그 통증으로 이어질 것입니다.

잠금, 교착 상태 및 DB가 디스크의 파일에 액세스하는 방법을 이해하면 올바른 방식으로 트리거를 사용하는 것 (예 : 감사 또는 직접 DB 액세스 아카이브)이 실제로 중요 할 수 있습니다.

그들이 악하다고 말하는 것은 격노이지만 메쉬를 일으킬 수 있습니다. 하나의 트리거 발생으로 인해 다른 트리거가 발생하면 실제로 복잡해집니다. 그들이 귀찮은 말을하자 : http://www.oracle.com/technology/oramag/oracle/08-sep/o58asktom.html

트리거로 Oracle에서 비즈니스 로직을 수행하는 것은 다중 동시성 문제로 인한 것보다 어렵습니다. 다른 세션이 커밋 될 때까지 다른 세션에서 변경 사항이 표시되지 않습니다.

그들은 분명히 악하지 않습니다. 데이터베이스 스키마를 리팩토링하거나 열의 이름을 바꾸거나 열을 두 개의 열로 나누거나 그 반대의 경우 (예 : 이름 / 성 사례) 및 전환을 지원하는 동안 트리거가 귀중한 것으로 나타났습니다.

또한 감사에 매우 유용합니다.

이 답변은 특히 SQL Server에 적용됩니다. (이것은 다른 RDBMS에도 적용될 수 있지만 전혀 알지 못합니다. 여기 에 답변으로 제공하고 싶지만 이것의 속임수로 닫혔습니다.)

지금까지 답변에서 언급되지 않은 한 가지 측면은 보안입니다. 기본적으로 트리거는 트리거를 발생시키는 명령문을 실행하는 사용자의 컨텍스트에서 실행되므로 모든 트리거를 검토하지 않으면 보안 위협이 발생할 수 있습니다.

BOL에서 " 트리거 보안 관리 "제목 아래에 제공된 예 는 GRANT CONTROL SERVER TO JohnDoe ;자신의 권한을 에스컬레이션하기 위해 코드 가 포함 된 트리거를 생성하는 사용자입니다 .

부작용이 있으면 의도적으로 문제입니다. 일부 데이터베이스 시스템에서는 자동 증분 필드, 즉 기본 키 ID 필드에 대한 다른 가능성이 없습니다.

나는 그들이 악할 수 있다고 생각하지만 개발중인 다른 것만 큼 악할뿐입니다.

나는 그들에 대해 많은 경험이 없지만 최근에 작업 한 프로젝트 에서이 결론을 이끌어 냈습니다. 내가 가진 문제는 비즈니스 로직이 코드 라이브러리 와 데이터베이스의 두 위치에서 끝날 수 있다는 것입니다 .

나는 그것을 sprocs를 사용하는 것과 비슷한 논쟁으로 본다. 비즈니스 로직을 데이터베이스에 쓰는 SQL에 능숙한 개발자가 종종 있고 다른 곳에서는 비즈니스 로직을 갖지 않을 것입니다.

그래서 제 규칙은 프로젝트의 구조가 무엇인지 살펴 보는 것입니다. 비즈니스 로직을 데이터베이스에 저장하는 것이 가능한 경우 트리거를 갖는 것이 유용 할 수 있습니다.

실제로, 종종 트리거가 잘못 사용되고 있습니다. 실제로 대부분의 경우 필요하지 않습니다. 그러나 이것이 반드시 나쁜 것은 아닙니다.

트리거가 유용한 시나리오는 소스 코드가없고 변경 방법이없는 레거시 애플리케이션이있는 경우입니다.

방아쇠에 대한 아이디어는 악한 것이 아니며 방아쇠의 중첩을 제한하는 것은 악합니다.