계정에서 수집하는 일일 비용을 추적하는 무언가를 작성하라는 요청을 받았으며이를 지원하는 데이터베이스 테이블 스키마를 알아 내려고 노력 중입니다.

내가 아는 것은 다음과 같습니다

• 회사는 250 만 개가 넘는 계정을 보유하고 있습니다.
• 이 중 현재 월 평균 200,000 명의 직원이 근무하고 있습니다 (현재 직원 수에 따라 변경됨).
• 그들은 추적하고 싶은 13 가지의 다른 비용 유형을 가지고 있으며, 앞으로 더 많은 것을 추가 할 것이라고 경고했습니다.
• 그들은 매일 비용을 추적하기를 원합니다
• 비용은 전체 재고에 분할되지 않습니다. 월 단위로 작동하는 계정 수 (200,000)로 분할되거나 사용자가 계정 식별자를 입력하여 계정 그룹에 비용을 적용하거나 단순히 비용을 적용 할 계정을 지정할 수 있습니다.

내 첫 번째 생각은 표준화 된 데이터베이스였습니다.

계정 ID
데이트
CostTypeId
양

이것에 대한 나의 문제는 수학을하는 것입니다. 이 테이블은 빠르게 커질 것입니다. 현재 한 달 동안 모든 13 개의 비용 유형이 모든 작업 계정에 적용된다고 가정하면 200k * 13 * N days in month, 이는 한 달에 약 7 천 8 백만에서 8 천만 건에 달하거나 매년 10 억 건에 가까운 레코드입니다.

내 두 번째 생각은 그것을 비정규 화하는 것이 었습니다

계정 ID
데이트
총비용
비용 유형 1
비용 유형 2
비용 유형 3
비용 유형 4
비용 유형 5
비용 유형 6
비용 유형 7
비용 유형 8
비용 유형 9
비용 유형 10
비용 유형 11
비용 유형 12
비용 유형 13

이 방법은 비정규 화 된 방식으로 한 달에 최대 6 백만 건 ( 200k * N days in month) 또는 연간 약 72 백만 건을 생성 할 수 있습니다 . 첫 번째 방법보다 훨씬 적지 만 향후 회사에서 새로운 비용 유형을 결정하는 경우 다른 데이터베이스 열을 추가해야합니다.

두 가지 방법 중 어느 것을 선호합니까? 왜? 더 잘 처리 할 수있는 다른 대안이 있습니까?

서머 닝 보고서와 상세 보고서 모두 성능보고에 가장 관심이 있습니다. 계정에 비용을 분산시키는 작업은 아무도 없을 때 밤마다 실행됩니다. 두 번째 관심사는 데이터베이스 크기입니다. 기존 데이터베이스는 이미 거의 300GB이며 디스크의 공간은 약 500GB라고 생각합니다.

데이터베이스는 SQL Server 2005입니다

답변

AccountDate
-----------
AccountId
Date
AcDtID (surrogate key)

Costs
-------
AcDtID
CostTypeId
Amount