2013-02-13 2 views
1

SQL Server 2008 데이터베이스 내에서 감사 결과를 보관할 테이블 구조를 설계하고 있습니다. 감사는 현재 65 개의 질문과 0-4 또는 N/A의 가능한 답을 가지고 있습니다. 이 데이터를 보유하기 위해 작성한 테이블 구조 (아직 테스트 중)가 아래에 설명되어 있습니다. 제출하면 각 질문에 대해 AuditDetail 테이블에 레코드가 만들어집니다. 선택한 응답이 0, 1 또는 2 인 경우 사용자는 왜 낮은지, 수정하는 방법 및 책임자 (AuditIssue 테이블에 레코드를 작성)를 설명하는 세부 사항을 입력해야합니다. 각 질문은 QuestionCategory 및 ItemCategory라는 두 가지 범주로 설명됩니다.감사를위한 데이터베이스 디자인 : 많은 행과 많은 열 대

제가 염려하는 문제는 현재 테이블 디자인에서 제출 된 각 감사에 대해 65 행이 AuditDetail 테이블에 추가된다는 것입니다. 이 감사는 매월 최소 70 회 완료해야합니다 (여러 부서에서 사용). 따라서이 테이블 구조는 매달 약 4550 개의 행을 AuditDetail 테이블에 추가합니다. 나는 이것이 미래의 성능에 부정적인 영향을 미칠 수 있으며 일단 이것을 프로덕션 환경으로 옮기면 테이블 구조를 재 설계하지 않아도 될지 걱정됩니다.

내가 만날 수있는 유일한 해결책은 AuditDetail 테이블을 각 질문에 대한 열이있는 테이블로 바꾸고 각 감사의 점수를 65 ​​행 이상의 1 행에 저장하는 것입니다.

나는 현재의 디자인이 정규화 규칙을 따르는 반면 나는 각 질문에 대한 열을 생성한다고 생각하지 않는다고 생각한다. 질문을 추가/삭제하고 기존 질문을 변경하는 것을 포함하여 질문이 미래에 (아마도 여러 번) 바뀔 것이라는 것은 거의 확실합니다. 이 문제에 대한 답변을

내 검색은이 두 가지 소스에 나를 인도 :
Many rows or many columns
Storing Answers In Columns

나는 그것을 추가 할 이상하지 않다고 이해가/때마다 질문 변경 열을 제거합니다. 제 질문은 월간 4550 행을 작성하면 쿼리 성능에 나쁜 영향을 미칩니 까? 내 상황이 "열에 응답 저장"에서 설명한 것과 동일한 지 여부는 알지 못합니다. 왜냐하면 테이블에 100 개의 행만있는 것으로 보이기 때문입니다. 쿼리의 성능이 크게 떨어지면 내가 생각하지 못한 더 나은 테이블 구조가 있습니까?

내 쿼리는 주로 매월 완료 감사, 마감 된 대 v 연체, 문제를 생성하는 상위 10 개 질문 및 월별 또는 일별 감사 점수 (Answer/Per Possible Points Per QuestionCategory) 또는 응답/총 가능한 포인트). 이 차트의 각 등 부서, 월, 지역에 의해 정렬 될 필요가있을 것이다

고백 : 나는 내가 아는이 차트의 일부를 생산하는 상관 하위 쿼리를 사용하게하는 경향이 이미 쿼리를 감소 공연. 나는 그들을 해결하려고 노력하지만, SQL 마스터가 아닌 나와 함께, 나는 그들에 갇혀있다.

**AuditMain:** 
--AuditId <-- PK 
--DeptNumber <-- FK to Dept Table 
--AuditorId <-- FK to Auditor Table 
--StartDate 
--Area_Id <-- FK to Area Table 

**AuditDetail** 
--DetailId <-- PK 
--QuestionId <-- FK to Question Table 
--Answer 
--NotApplicable (boolean to determine if they chose N/A, needed to calcualte audit score) 
--AuditId <-- FK to AuditMain 

**AuditIssue** 
--IssueId <-- PK 
--IssueDescription 
--Countermeasure 
--PersonResponsible 
--Status 
--DueDate 
--EndDate 
--DetailId <--FK to AuditDetail 

**AuditQuestion** 
--QuestionId <-- PK 
--QuestionNumber (corresponds to the question number on the audit input form) 
--QuestionDescription 
--QuestionCategoryId <-- FK to QuestionCategory 
--ItemCategoryId <-- FK to ItemCategory 

**QuestionCategory** 
--QuestionCategoryId <-- PK 
--CategoryDescription 
--CategoryName 

**ItemCategory** 
--ItemCategoryId <--PK 
--ItemCategoryDescription 

덕분에 너무 많은 설명을 통해 읽기 위해 다음과 같이

내가 테스트를 위해 사용하고 현재 테이블 구조입니다. 너무 적은 정보보다는 너무 많은 정보의 측면에서 실수를하고 싶었지만 추가 정보가 필요한지 알려주십시오. 나는 모든 제안에 감사드립니다!

답변

0

프로덕션 환경이 심각하게 부족한 경우가 아니면 성능을 심각하게 저하시키지 않고 테이블에 50 만 행을 보유 할 수 있어야합니다. 검색 성능은 쿼리에 사용하는 필드와 인덱스를 작성한 필드의 영향을 크게받습니다. 이것은 witing 초와 대기 분 사이의 차이를 만들 수 있습니다.

여기에 들어가기에는 너무 많은 세부 사항이 있지만 데이터베이스 디자인에 대한 많은 훌륭한 자습서가 있습니다. 이 튜토리얼의 최고는 성능뿐만 아니라 미래의 유연성을 디자인하는 방법을 가르쳐 줄 것입니다. 이는 마찬가지로 중요합니다.

당신의 테이블 구조는 언뜻보기에 꽤 좋아 보입니다.