2012-01-21 3 views
0

제품 및 고객별로 주별 및 월별 판매 데이터를 동적으로 업데이트해야합니다. 이러한 것들은 제품을 판매하는 동안 업데이트하고 검사해야하며 여러 가지 이유로 스토어드 프로 시저 또는 구체화 된 뷰를 사용할 수 없습니다 (응용 프로그램으로 모든 것을 읽은 다음 모든 것을 메모리에서 수정 한 후 업데이트합니다). 결과를 저지하십시오).Oracle에서 주간 및 월간 집계 저장

기간 동안 판매를 유지하는 데 가장 적합한 테이블 구조는 무엇입니까?

  • 기간 유형 (M, W)을 시작일과 종료일 또는 유형 및 시작일 만 저장 하시겠습니까?
  • 날짜 필드와 char을 사용하거나 문자열 ('M201201'/ 'W201248')에 코드화
  • 영업 및 기간을 두 테이블로 정규화하거나 판매 및 기간을 단일 테이블에 유지 하시겠습니까?

현재 주간 (xor 월간) 기간/고객/기사의 판매를 선택하고 업데이트하지는 않지만 고객/기사의 주간 및 월간 기간 업데이트를 선택합니다.

답변

1

해당 기간의 시작 날짜와 종료 날짜를 행에 모두 저장하면 검색 쿼리가 훨씬 간단해질 수 있습니다. 적어도 오늘 같은 단일 날짜를 기반으로 한 검색 쿼리가 훨씬 쉽습니다. 이는 특정 날짜에 발생하는 특정 거래와 같은 비즈니스 트랜잭션의 관점에서 사물을 보게 될 것이므로 매우 일반적인 액세스 모드입니다.

where @date_of_interest >= start_date and @date_of_interest <= end_date은 매우 직접적이고 간단합니다. 다른 조합을 사용하면 쿼리로 이동하기 전에 코드에서 또는 쿼리 자체에서 날짜 산술을 수행해야합니다.

시작일과 종료일뿐만 아니라 유형 코드 (M, W)를 유지하면 약간의 중복성이 발생합니다. 그러나 데이터 검색을 용이하게하기 위해이 중복성을 도입 할 수도 있습니다. 이것은 : where @date_of_interest >= start_date and @date_of_interest <= end_date and range_type='M' 또한 매우 직접적이고 간단합니다.

모든 비정규 화와 마찬가지로이 중복성을 관리 할 컨트롤이 있는지 확인해야합니다.

+0

감사합니다, 날짜 연산에 대한 좋은 점과 같은 아마 뭔가 - 내 초기 우려도 있었다. 불행히도, 나는 항목을 만들 때 올바른 날짜를 써야하기 때문에 나는 그것을 피할 수 없을 것입니다 - 우리 ORM 프레임 워크 때문에 TRUNC (@ date_of_interest, 'IW')를 단순히 사용할 수 없습니다. –

0

동일한 구조의 두 테이블에 주별 및 월별 집계를 저장하는 정규화 된 스키마를 사용하는 것이 좋습니다. 나는 당신이 할 쿼리의 종류를 모른다. 그러나 이것이 어떤 종류의 검색이라도 더 쉽게 할 수 있다고 생각한다.

이 샘플

product_prices (
    prod_code, 
    price, 
    date_price_begin 
); 

sales (
    prod_code, 
    customer_code, 
    sale_date 
); 


<aggregate-week> 
select trunc(sale_date,'w') as week, 
    prod_code, 
    customer_code, 
    sum(price) keep (dense_rank first order by date_price_start) as price 
from sales 
    natural join product_prices 
where sale_date > date_from 
group by trunc(sale_date,'iw'), 
    prod_code, 
    customer_code 
/

<aggregate-month> 
select trunc(sale_date,'m') as month, 
    prod_code, 
    customer_code, 
    sum(price) keep (dense_rank first order by date_price_start) as price 
from sales 
    natural join product_prices 
where sale_date > date_from 
group by trunc(sale_date,'m'), 
    prod_code, 
    customer_code 
/
+0

실제 SQL 집계를 수행 할 수 없으며 한 번 (보기를 사용하여) 시도했지만 충분하지 않았습니다 (모든 주문 행에 대해 집계 된 판매 데이터를 점검해야 함). 또한 전체 기간 동안 판매 된 실제 조각 수에 관심이 있습니다.이 기간의 가격은 처음이 아닙니다. 인덱스가있는 테이블 하나 또는 두 개의 파티션이있는 단일 테이블 대신 두 개의 테이블을 사용하면 어떤 이점이 있습니까? –

+0

나는 그 쿼리가 어떻게 느려지는지 상상할 수 없다 !! 그들이 사용하는 테이블은별로 크지 않을 것이고 (각 행에 대해 50 바이트 미만), 집계 테이블은 점차적으로 (매주/월말마다 새 행을 추가하여) 빌드 될 수 있습니다. 어쨌든 나는 그 사건을 시험 할 것이고, 나는 결과를 내 포스트에 올릴 것이다. –

+0

나는 당신이 오해 한 것 같아요. 일주일이 끝난 후에는 주간 집계가 필요 없어요. 일주일 동안 (재고 보관의 일환으로) 필요합니다. 즉 수요일 13:45에 고객 100,000의 123456 제품을 처리 할 때 월요일 00:00에서 수요일 거래 시작까지 기사의 총 판매가 필요합니다. 내가 고객에게 제품을 판매하기를 원할 때마다 나는 판매 데이터에 'SELECT .. GROUP BY'를해야하는데, 데이터베이스는 계속 유지할 수 없습니다. 그래서 매 판매 후 집계의 증분 업데이트를 수행해야합니다. –

관련 문제