트리거 및 제약 조건에 대한 성능 고려 사항

https://stackoverflow.com/questions/148129

02-07-2019
|

문제

데이터베이스 내부의 트리거 또는 제약 조건에서 비즈니스에 중요한 논리를 사용해야 하는지 알아보려고 합니다.
지금까지는 다음에 일어날 일을 제어할 수 있고 사용자를 혼란스럽게 할 오류 대신 사용자 지정 사용자 메시지를 제공할 수 있다는 의미로 트리거에 논리를 추가했습니다.

트리거에 대한 제약 조건을 사용할 때 눈에 띄는 성능 향상이 있습니까? 그리고 사용할 항목을 결정하기 위한 모범 사례는 무엇입니까?

해결책

제약 조건은 손을 내립니다!

제약 조건을 사용하면 관계 원칙, 즉 데이터에 대한 사실을 지정합니다. 사실이 변경되지 않는 한 (예 : 새로운 요구 사항) 제약 조건을 변경할 필요가 없습니다.
트리거를 사용하면 데이터를 처리하는 방법 (인서트, 업데이트 등)을 지정합니다. 이것은 "비 관계형"일을하는 방법입니다.

비유로 나 자신을 더 잘 설명하려면 : SQL 쿼리를 작성하는 올바른 방법은 "얻는 방법"대신 "원하는 것"을 지정하는 것입니다. RDBMS가 당신을 위해 가장 좋은 방법을 알아낼 수 있습니다. 트리거를 사용하는 경우 실행 순서, 계단식 등과 같은 다양한 것들을 염두에 두어야합니다 ... 가능한 경우 제약 조건으로 SQL을 수행하도록하십시오.

그것은 트리거가 용도가 없다고 말하는 것이 아닙니다. 그렇습니다 : 때로는 제약 조건을 사용하여 데이터에 대한 사실을 지정할 수 없습니다. 그래도 극히 드 rare니다. 그것이 당신에게 일어난다면 많이, 그런 다음 스키마에 문제가있을 수 있습니다.

다른 팁

모범 사례: 제약으로 할 수 있다면 제약 조건을 사용하십시오.

트리거는 가능한 한 항상 제약을 사용하지만 (올바르게 사용하는 경우) 불신만큼 나쁘지는 않습니다. 최신 RDM에서 트리거의 성능 오버 헤드는 제약 조건과 비슷합니다. (물론 그렇다고해서 누군가가 방아쇠에 끔찍한 코드를 놓을 수 없다는 것을 의미하지는 않습니다!).

때로는 트리거를 사용하여 테이블의 두 개의 외국 키 필드 중 하나만이 채워진다는 것과 같은 '복잡한'제약 조건을 시행해야합니다 (몇 가지 도메인 모델 에서이 상황을 보았습니다).

비즈니스 논리가 DB가 아닌 응용 프로그램에 존재하는지 여부에 대한 논쟁은 환경에 어느 정도 달려 있습니다. DB에 액세스하는 응용 프로그램이 많으면 제약과 트리거가 모두 데이터가 올바른 최종 가드 역할을 할 수 있습니다.

트리거는 성능 문제로 꽃을 피울 수 있습니다. 거의 같은 시간에 그들은 또한 유지 보수 악몽이되었습니다. 무슨 일이 일어나고 있는지 알 수 없습니다 그리고 (보너스!) 응용 프로그램은 "스퓨리어스"데이터 문제로 불규칙하게 작동합니다. [정말로, 그들은 트리거 문제입니다.

최종 사용자가 SQL에 직접 닿지 않습니다. 그들은 응용 프로그램을 사용합니다. 응용 프로그램에는 트리거보다 훨씬 똑똑하고 유지 관리 가능한 방식으로 비즈니스 논리가 포함되어 있습니다. 응용 프로그램 논리를 응용 프로그램 프로그램에 넣으십시오. 데이터베이스에 데이터를 넣으십시오.

귀하와 귀하의 "사용자"가 공통 언어를 공유하지 않으면 제약 위반을 설명 할 수 있습니다. 설명이 아닌 대안은 간단한 데이터베이스를 데이터와 응용 프로그램 코드를 인재 할 수없는 Quagmire로 혼합하기 때문에 문제로 전환합니다.

"모든 사람이 데이터 모델을 올바르게 사용하고 있다는 절대적인 확신을 얻는 방법은 무엇입니까?"

두 가지 (및 절반) 기술.

모델이 있는지 확인하십시오 오른쪽: 실제 문제 도메인과 일치합니다. 복잡한 손을 흔들리는 설명, 저장된 절차 및 트리거를 통해서만 분류 할 수있는 해킹이나 해결 방법 또는 바로 가기가 없습니다.
응용 프로그램의 비즈니스 모델 계층을 정의하는 데 도움이됩니다. 모든 사람이 공유하고 재사용하는 응용 프로그램 코드 계층.

ㅏ. 또한 모델 레이어가 사람들의 요구를 충족해야합니다. 모델 레이어에 올바른 방법과 컬렉션이있는 경우 기본 데이터에 직접 액세스하기 위해이를 우회 할 인센티브가 적습니다. 일반적으로 모델이 옳다면 이것은 심오한 관심사가 아닙니다.

트리거는 열차가 일어나기를 기다리고 있습니다. 제약 조건은 아닙니다.

구속 조건을 사용해야하는 다른 이유 외에도 Oracle Optimizer는 제약 조건을 사용하여 이점을 사용할 수 있습니다.

예를 들어, 제약이있는 경우 (Amount >= 0) 그리고 당신은 함께 쿼리합니다 WHERE (Amount = -5) 오라클은 일치하는 행이 없다는 것을 즉시 알고 있습니다.

제약 조건과 트리거는 서로 다른 두 가지 용도로 사용됩니다.제약 조건은 다음과 같은 데 사용됩니다. 억누르다 데이터의 도메인(유효한 입력).예를 들어 SSN은 char(9)로 저장되지만 제약 조건은 [0-9][0-9][0-9][0-9][0-9][0-9][입니다. 0-9][0-9][0-9] (모두 숫자).

트리거는 비즈니스를 실행하는 방법입니다. 논리 귀하의 데이터베이스에.SSN을 다시 살펴보면 SSN이 변경될 때마다 감사 추적을 유지해야 할 수 있습니다. 이는 트리거를 사용하여 수행됩니다.

일반적으로 최신 RDBMS의 데이터 무결성 문제는 몇 가지 제약 조건을 변형하여 처리할 수 있습니다.그러나 때로는 부적절한 정규화(또는 변경된 요구 사항으로 인해 부적절한 정규화가 발생함)로 인해 제약 조건이 방해되는 상황에 빠지게 됩니다.이 경우 트리거는 제약 조건을 적용할 수 있지만 RDBMS에는 불투명하므로 최적화에 사용할 수 없습니다.이는 또한 "숨겨진" 논리이며 유지 관리 문제가 될 수 있습니다.스키마를 리팩터링할지 아니면 트리거를 사용할지 결정하는 것은 그 시점에서 판단해야 합니다.

일반적으로 나는 제약 조건을 선호하고 내 코드는 SQL Server 오류를 포착하고 사용자에게 더 친숙한 것을 나타냅니다.

@onedayway

SQL Server에서 쿼리를 제약으로 가질 수 있으므로 스칼라 기능으로 맞출 수 있어야합니다.http://www.eggeadcafe.com/software/aspnet/30056435/check-contraints-and-tsql.aspx

@Mark Brackett : "제약 조건은 도메인을 제한하는 데 사용됩니다 ... 트리거 트리거는 비즈니스 로직을 시행하는 방법입니다." 시간적 데이터베이스 테이블에서 시퀀싱 된 '기본 키'의 전형적인 예를 들어보십시오. 이상적으로는 동일한 엔티티의 겹치는 기간을 방지하기 위해 하위 쿼리와 함께 확인 제약을 사용하지만 SQL Server를 사용할 수 없으므로 사용해야합니다. 방아쇠. 또한 SQL 서버에서 누락 된 것은 SQL-92 제약 조건 검사를 연기 할 수있는 능력이 있지만 대신 모든 SQL 명령문 후에 (사실상) 점검되므로 SQL Server의 한계를 중심으로 작동하는 데 다시 트리거가 필요할 수 있습니다.

가능한 모든 사용 제약 조건. 그들은 더 빠른 경향이 있습니다. 트리거는 제약 조건을 처리 할 수없는 복잡한 논리에 사용해야합니다. 트리거 쓰기도 까다 롭고 트리거를 작성해야한다면 트라이 지어가 전체 삽입, 업데이트 또는 삭제에 대해 작동하기 때문에 세트 기반 진술을 사용해야합니다 (예, 한 레코드 이상의 레코드가 영향을받는 시간이있을 것입니다. 그것에!), 한 번에 하나의 레코드가 아닙니다. 피할 수있는 경우 트리거에서 커서를 사용하지 마십시오.

트리거 또는 제약 대신 응용 프로그램에 논리를 넣을지 여부. 그거 하지마!!! 예, 응용 프로그램은 데이터를 보내기 전에 점검해야하지만 데이터 무결성 및 비즈니스 로직은 데이터베이스 수준에 있거나 여러 응용 프로그램이 연결되면 글로벌 삽입물이 애플리케이션 등을 수행 할 때 데이터가 엉망이됩니다. 무결성은 데이터베이스의 핵심이며 데이터베이스 수준에서 시행해야합니다.

@Meff : SQL Server Check 제약 조건은 작업 단위로 단일 행으로 설계되었으며 결과 세트에서 작업 할 때 결함이 있기 때문에 기능 사용 접근 방식에는 잠재적 인 문제가 있습니다. 이에 대한 자세한 내용은 다음을 참조하십시오. [http://blogs.conchango.com/davidportas/archive/2007/02/19/trouble-with-check-songraints.aspx▪]]].

1] : David Portas의 블로그 : 점검 제약 문제 문제.

skliwz와 동일합니다. 당신에게 알리기 위해 방아쇠의 표준 사용 감사 테이블입니다. 많은 절차가 감사하려는 테이블을 업데이트/삽입/삭제하면 (무엇을 수정했는지, 언제 수정했는지) 트리거가 가장 간단한 방법입니다. 한 가지 방법은 단순히 테이블에 플래그를 추가하는 것입니다 (단일 제약 조건으로 활성/비활성)가 감사 테이블에 무언가를 삽입하는 것입니다.

다른 방법으로 테이블이 과거 데이터를 보유하지 않기를 원한다면 감사 테이블의 이전 행을 복사하는 것입니다 ...

많은 사람들이 여러 가지 방법을 가지고 있습니다. 그러나 한 가지 확실한 점은이 테이블에서 각 업데이트/삽입/삭제에 대한 삽입물을 수행해야합니다.

여러 곳에서 삽입물을 쓰지 않으려면 여기에서 트리거를 사용할 수 있습니다.

제약 조건에 대해 여기 모든 사람과 동의합니다. 가능한 한 많이 사용하십시오.

특히 새로운 개발자들에게 트리거를 과도하게 사용하는 경향이 있습니다. 트리거가 다른 트리거를 발사하는 상황을 보았습니다. 다른 트리거를 발사하여 첫 번째 트리거를 반복하는 다른 트리거를 발사하여 서버를 연결하는 계단식 트리거를 만듭니다. 이것은 트리거의 최적이 아닌 사용자입니다; o)

즉, 방아쇠는 자신의 자리가 있으며 적절한 경우 사용해야합니다. 마크 브라켓 (Mark Brackett)이 언급 한 바와 같이 데이터의 변화를 추적하는 데 특히 좋습니다. "내 비즈니스 논리를 넣는 것이 가장 의미가있는 곳"이라는 질문에 대답해야합니까? 대부분의 경우 나는 그것이 코드에 속한다고 생각하지만 당신은 열린 마음을 유지해야합니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow