【发布时间】：2013-01-29 07:39:00
【问题描述】：
我正在 SQL Server 2008 数据库中设计一个用于保存审计结果的表结构。审计目前有 65 个问题和 0-4 或 N/A 的可能答案。下面描述了我为保存这些数据（仍在测试中）而创建的表结构。提交后，会在 AuditDetail 表中为每个问题创建一条记录。如果选择的答案是 0、1 或 2，则用户必须输入详细信息，描述为什么低、如何修复以及谁负责（这会在 AuditIssue 表中创建一条记录）。每个问题由两个不同的类别描述，分别名为 QuestionCategory 和 ItemCategory。
我担心的问题是，在我当前的表设计中，每次提交的审计都会在 AuditDetail 表中添加 65 行。这个审计每个月至少需要完成70次（很多部门都在用）。因此，此表结构每月将向 AuditDetail 表添加大约 4550 行。我担心这可能会对未来的性能产生负面影响，并且希望避免在将其移入生产环境后重新设计表结构。
我能想出的唯一其他解决方案是将 AuditDetail 表替换为一个表，该表包含每个问题的列并将每次审计的分数存储在 1 行中，跨越 65 列以上。
我觉得我当前的设计遵循规范化规则，而我认为不会为每个问题创建一个列。我几乎可以肯定，这些问题将来会发生变化（可能会发生很多次），包括添加/删除问题和更改现有问题。
我在寻找这个问题的答案时找到了这两个来源：
Many rows or many columns
Storing Answers In Columns
我了解每次问题更改时添加/删除列并不理想。 我的问题是每月创建 4550 行会对我的查询性能产生多大的影响？我不知道我的情况是否与“将答案存储在列中”中描述的情况相同，因为看起来他们的表中只会有 100 行。 如果查询的性能会大幅下降，有没有更好的表结构是我没想到的？
我的查询将主要用于生成图表，显示每月完成的审计总数、打开的问题、已关闭的问题和过期问题、产生问题的前 10 个问题以及每月或每日审计分数（答案/每个问题类别或答案的可能总分/总可能点）。这些图表中的每一个都需要按部门、月份、区域等进行排序。
忏悔：我最终倾向于使用相关子查询来生成其中一些图表，我知道这已经降低了查询性能。我尝试解决它们，但由于我不是 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
感谢您阅读这么多解释。我想在信息过多而不是过少方面犯错，但是如果需要任何进一步的信息，请告诉我。我很感激任何和所有的建议！
【问题讨论】：
标签： sql database-design query-performance