2011-09-08 3 views
9

Ruby on Rails와 PostgreSQL을 사용하여 프로그램을 작성하고 있습니다. 이 시스템은 자주 업데이트되고 사용자가 자주 액세스하는 많은 보고서를 생성합니다. 필자는 Postgres 트리거를 사용하여 보고서 테이블 (Oracle Materialized View와 같은) 또는 ActiveRecord 콜백으로 빌드 된 레일스를 생성해야하는지 여부를 결정합니다. 누구든지 이것에 대한 생각이나 경험이 있습니까?데이터베이스 트리거 대 장단점과 레일스 ActiveRecord 콜백 비교

답변

12

콜백은 다음과 같은 경우에 유용합니다

  • 가있는 용이성의 유지 보수 레일 모델의 모든 비즈니스 로직을 결합합니다.

    :
  • 루비 코드를 디버깅하는 기존의 레일 모델 코드
  • 쉬운의
  • 만들기 사용은 SQL "유지 보수"

트리거는 다음과 같은 경우에 유용보다 읽기/기록하는 것이 더 쉽습니다

  • 성능에 큰 문제가 있습니다. 콜백보다 빠릅니다.

걱정이된다면 콜백을 사용하십시오. 당신의 관심사가 성과 인 경우에, 방아쇠를 이용하십시오.

+0

트리거를 사용할 때 성능이 향상되는 이유는 무엇입니까? – Zubair

+1

콜백에서 DB에 연결하기 때문에 트리거에 이미 db 계층에 연결되어있는 db에 연결할 필요가 없습니다. –

+0

Ah가 의미가 있습니다.감사합니다 – Zubair

5

우리는 똑같은 문제가 있었는데, 이것은 흥미로운 주제이므로, 우리의 선택/경험을 토대로 정교하게 다룰 것입니다.

나는 현재의 대답에 강조 표시된 것보다 더 복잡한 개념이라고 생각합니다.

보고서에 대한 이야기이므로 유스 케이스가 "일반"응용 프로그램이 아니라 데이터웨어 하우징 테이블을 업데이트한다고 가정합니다 (이 가정/구분이 중요합니다).

첫째, "디버그하기 쉬운"아이디어가 반드시 필연적 인 것은 아닙니다. 우리의 경우, 그렇게 생각하는 것은 실제로 비생산적입니다.

충분히 복잡한 응용 프로그램에서는 데이터베이스가 너무 많은 장소/방법으로 인해 콜백 (데이터웨어 하우징 업데이트/수백만 줄의 코드/중급 (또는 그 이상) 크기 팀)의 유지 관리가 불가능합니다. 콜백을 놓친 것을 디버깅하는 것은 사실상 불가능할 것이라고 업데이트했습니다.

트리거가 반드시 "복잡하고 빠른"논리로 디자인 될 필요는 없습니다. 특히 트리거는 저수준 콜백 로직으로도 작동 할 수 있으므로 간단하고 부담이 적습니다. 업데이트 이벤트를 레일스 코드로 다시 전달하기 만합니다.

언급 한 사용 사례에서 레일스 콜백은 전염병처럼 피해야합니다.

효율적이고 효과적인 설계는 RDBMS 트리거를 사용하여 레코드를 큐 테이블에 추가하고 레일스 대기열 시스템이이를 통해 작동합니다.

(이 게시물은 오래되었으므로 OP에 대해 궁금한 점이 있습니까)

관련 문제