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

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

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

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

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



답변

트리거의 주요 문제는

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

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


답변

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

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

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

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


답변

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


답변

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

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

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

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

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


답변

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


답변

대부분 그렇습니다.

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

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

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


답변

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

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

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