我正在设计SQL Server 2008数据库中的一个表结构，该数据库将保存审计结果。审计目前有65个问题和0-4或N/A的可能答案。下面描述了我为创建该数据而创建的表结构（仍在测试中）。提交后，将在AuditDetail表中为每个问题创建一条记录。如果选择的答案是0,1或2，则用户必须输入描述为什么较低，如何解决以及谁负责的细节（这会在AuditIssue表中创建一条记录）。每个问题由两个不同的类别描述，分别命名为QuestionCategory和ItemCategory。用于审计的数据库设计：用于答案和许多列的许多行
我担心的问题是，使用我当前的表设计，将为审计提交的每个审计详细信息表添加65行。这个审计需要每月至少完成70次（许多部门使用它）。所以这个表结构将每月向AuditDetail表添加大约4550行。我担心这可能会对未来的性能产生负面影响，并希望一旦将其转移到生产环境中，就不必重新设计表结构。
我唯一能想出的另一个解决方案是用一个有每列问题列的表替换AuditDetail表，并将每个审计的得分存储在65列以上的1行中。
我觉得我目前的设计遵循规范化规则，但我不认为为每个问题创建一个列会。我几乎可以肯定，这些问题将在未来发生变化（可能是很多次），包括增加/删除问题和改变现有问题。
我的回答这个问题，搜索使我这两个来源：
Many rows or many columns
Storing Answers In Columns
我的理解，它不会是理想的添加/删除列，每次一个问题的变化。 我的问题是，每月创建4550行会对我的查询性能产生多大的影响？我不知道我的情况是否与在“在列中存储答案”中描述的情况相同，因为它们似乎只是在其表中有100行。 如果查询的性能将大大降低，是否有更好的表格结构，我还没有想到？
我的查询将主要用于生产开业VS封闭VS逾期图表这表明总审计完成月度，问题，产生问题的前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
感谢您在这么多的解释阅读。我想在信息太多而不是太少的情况下犯错，但请让我知道是否需要进一步的信息。我感谢任何和所有的建议！