필드에 합계 값을 저장하는 것과 다른 테이블에서 sum() 연산을 수행하는 것에 대한 장단점에 대해 궁금합니다. 예를 들어 각 항목의 구매 횟수와 함께 항목 목록을 검색 할 수 있습니다. 이 경우 Items 테이블과 Purchases 테이블을 가지고 구매를 합산해야합니다. 합산 값필드에 합계 값 저장 대 테이블 (MYSQL)에 sum() 저장
찬반 :
sum()의 (NO JOIN의 필요 예 Items.item_id=Purchases.item_id)찬반 :
UPDATE이 필요하기 때문에 동기화되지 않을 수있는 값을 얻는 방법을 유지해야합니다. 및INSERT 문을 변경합니다 (예를 들면, Purchases 테이블 에서 구입 INSERT 및Items의 purchase_count 필드의 UPDATE.이러한 질문에 대한 올바른 대답은 아닙니다. 대답은 전적으로 데이터 사용 방법에 달려 있습니다.
두 가지 극단. 데이터를 거의 조회하지 않고 기록 데이터에 많은 변경 사항이있는 경우, 시스템은 필요하지 않을 때 합계를 일관되게 유지하는 데 많은 시간을 소비 할 수 있습니다.
반면에 데이터가 "삽입 전용"이고 모든 레코드가 합계와 함께 반복적으로 검색되는 경우 합계가 있으면 노력이 절약됩니다.
일반적으로 비즈니스 규칙으로 유지하는 대신 쿼리 시간에 sum()을 수행하는 것이 더 일반적인 방법입니다. 한 가지 분명한 이점은 값이 시간이 지남에 따라 일관된다는 것입니다.
두 번째 이점은 분석이 다를 수 있다는 것입니다. 어쩌면 오늘 당신은 항목의 개수가 필요합니다. 어쩌면 다음 주에, 당신은 단위의 수를 필요로합니다. 그리고 달러의 계산. 또는 순 가격 차이. 시간이 지남에 따라 변합니다. 그들 모두를 앞에 붙잡 으려 노력하는 것은 어렵습니다.해결책은 문제를 두 부분으로 나누는 것입니다. 하나의 "데이터베이스"에 정규화 된 데이터를 저장합니다 (마법의 합계가 없음). 최종 사용자 목표에 맞게 수정할 수있는 "데이터 마트"에 상점 요약을 저장합니다. 데이터 마트는 주기적으로 업데이트됩니다 (하루에 한 번 또는 일주일에 한 번).
기간 요약이있는 정규화 된 기본 데이터는 다양한 요구를 충족하는 강력한 아키텍처입니다. 그러나 select이 아닌 insert/update/delete의 계산을하는 것이 더 좋은 경우가 있습니다. 이러한 솔루션은 종종 복잡성 (인스턴스에 대한 다중 트리거)을 필요로하기 때문에 더 표준화 된 솔루션보다 강력하게 정당화해야합니다.
응용 프로그램의 특성과 용도에 따라 다릅니다.
검색어 중 어느 것이 더 자주 사용되는지 (기존 애플리케이션의 경우) 계산하거나 검토해야합니다. 쿼리의 DML 유형 :
SELECT 쿼리에 대한 적합 - 예를 들어 일반 전자 상점에 대한 .UPDATE/INSERT 쿼리 적합 - 예를 들어 무거운 매장 응용 프로그램을 중심으로 매장 재고 관리 로 구성되어 있습니다.