用于审计的数据库设计:多行答案与多列

Question

我正在Server 2008数据库中设计一个表结构，它将保存审计结果。审计目前有65个问题和0-4或N/A的可能答案。下面描述了我为保存这些数据而创建的表结构(仍在测试中)。提交后，将在AuditDetail表中为每个问题创建一个记录。如果选择的答案为0、1或2，则用户必须输入详细信息，说明为什么低、如何修复以及谁负责(这将在AuditIssue表中创建记录)。每个问题都由两个不同的类别来描述，分别是QuestionCategory和ItemCategory。

我关心的问题是，在我当前的表设计中，每个提交的审计都会将65行添加到AuditDetail表中。这一审计每月至少需要完成70次(许多部门都在使用)。因此，该表结构将每月向AuditDetail表添加大约4550行。我担心这可能会对未来的性能产生负面影响，并希望避免在我将其引入生产环境后不得不重新设计表结构。

我能想出的唯一其他解决方案是将AuditDetail表替换为一个表，该表对每个问题都有一个列，并在65+列中将每个审计的分数存储在1行中。

我觉得我目前的设计是遵循规范化规则的，而我不认为为每个问题创建一列就可以了。我几乎可以肯定，这些问题将来会改变(也许很多次)，包括增加/删除问题和改变现有的问题。

我寻找这个问题的答案使我找到了以下两个来源：

Many rows or many columns

Storing Answers In Columns

我的理解是，每次问题更改时添加/删除列并不理想。我的问题是，每月创建4550行将对我的查询的性能产生多大的影响？，我不知道我的情况是否与“在列中存储答案”中描述的情况相同，因为它们的表中似乎只有100行。如果查询的性能将急剧下降，是否有更好的表结构我没有想到？

我的查询将主要用于生成图表，这些图表显示每月完成的审计总数、已打开的问题与已结束的和过期的问题、产生问题的前10位问题以及每月或每日审计评分(答案/每个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 

谢谢你阅读了这么多的解释。我想错误的一方太多的信息，而不是太少，但请告诉我，如果有任何进一步的信息是需要的。我非常感谢所有的建议！

Answer 1

除非您的生产环境动力严重不足，否则它应该能够在一个表中容纳50万行，而不会严重降低性能。检索性能将受到用于查询的字段和已构建索引的字段的极大影响。这可以在几秒钟和等待分钟之间做出区别。

这里有太多的细节，但是有很多关于数据库设计的优秀教程。最好的这些主题将教你如何设计不仅为了性能，而且为未来的灵活性，这是同样重要的。

乍一看，你的桌子结构看上去不错。