规范化数据库所需的建议答案

【问题标题】：Advice Needed To Normalise Database规范化数据库所需的建议
【发布时间】：2011-01-31 05:51:36
【问题描述】：

我试图在 ASP.net 中为反馈应用程序创建一个数据库，我有以下数据库设计。

Username (PK)

QuestionNo (PK)
QuestionText

FeedbackNo (PK)
Username

UserFeedbackNo (PK)
FeedbackNo (FK)
QuestionNo (FK)
Answer
Comment

用户拥有唯一的用户名一个用户可以有多个反馈

我想知道我这里的数据库设计是否规范化并适合应用程序

编辑 - 一个反馈有多个问题，因此会有多个反馈答案。希望这是有道理的

编辑 - 我在反馈表中有 20 个问题，每个问题都可以使用单选按钮来回答（因此是“答案”字段），并且可以将可选的 cmets 添加到每个问题中。用户可以根据需要多次填写此反馈表。这就是为什么我有包含 feedbackNo 和用户名的链接表的原因。

编辑

**Users Table**
UserID (PK) autonumber
Username

**Question Table**
QuestionID (PK) autonumber
QuestionNumber
QuestionText

**Questionnaire Table**
QuestionnaireID  (PK) autonumber
UserID (FK) `User Table`
Date

**Feedback Table**
ID (PK) autonumber
QuestionnaireID (FK) `Questionnaire Table`
QuestionID (FK) `Questions Table`
Answer
Comment

阅读完 cmets ... 我是否会重新设计我的设计，这个新设计是否适合我的需求？

【问题讨论】：

为什么 20 个反馈问题不只是在问题表中？可能 QuestionType='F'??
您的第三组编辑对我来说看起来不错。
@Phil，第三次编辑和我原来的帖子几乎一样，唯一的区别是我在问卷表中添加了一个日期字段，并且我已经重命名了一些字段！ @KM，我不太明白你的意思
我认为您的原始设计接近正确，正如我在完整答案中所说的那样。您确实在第三次编辑中更正了自然/代理键问题和最终表/字段名称（“UserFeedbackNo”）。
据我了解您的需求，看起来不错。

标签： asp.net sql database-design normalization

【解决方案1】：

根据您的修改，我认为您的设计是正确的 - 反馈表代表用户的问题/答案的集合，其中最后一个表定义了给出的各个答案。我不会在最后一个表的名称/PK 中包含“用户”一词，因为它是定义用户的反馈表。称之为“FeedbackAnswer”。

此外，您正在混合代理键和自然键（用户名作为键与 FeedbackNo 作为键）。这是一个关于哪个更好的争论问题，但我相信更多的人会同意你应该坚持一种方法或另一种方法，而不是混合它们（如果可能的话）。

最后，如果用户要从可能的响应列表中选择答案，请考虑使用 QuestionAnswer 表来定义 wach 问题的响应，然后该表将与 FeedbackAnswer 表相关联并更好地规范化响应数据。

【讨论】：

我的回答是基于您的第二次编辑，不包括您的第三次（使用新表格设计）。

【解决方案2】：

你那里有一张无关的桌子。看起来您在反馈和用户之间存在多对多的关系。但是，反馈仅与一位用户有关。基数应该是：

每个反馈一个用户
每个反馈一个问题

你的结构应该是这样的：

用户表

用户名（PK）

问题表

ID (PK)
问题文本

反馈表

ID (PK)
用户名 (FK)
QuestionId(FK)
回答
评论

随着 c11ada 提供的更新，设计得以保留。在您的情况下，我可能做出的唯一区别是我会将答案的日期和时间存储在反馈表中。

另一种方法是创建另一个表，即问卷调查表，该表将记录用户填写的反馈实例。

问卷表

ID (PK)
用户名 (FK)
日期

反馈表

ID (PK)
QuestionnaireId (FK)
QuestionId(FK)
回答
评论

这是假设调查问卷不是关于其他用户的。在这种情况下，它看起来像：

问卷表

ID (PK)
关于用户 (FK)
AnsweringUser (FK)
日期

【讨论】：

我也是这么想的；但是，如果单个反馈包含多个问题的答案，那么问题中的设计将是有意义的，除了 PK UserFeedbackNo，它可能是 QuestionFeedbackNo。 OP 可能想首先澄清他想要完成的工作。
我想我应该再澄清一下。我的反馈表中有大约 20 个问题，用户可以多次填写此反馈表，每个问题的答案都需要存储。
+1 感谢所有的帮助！！你能检查我的最终编辑...看起来对吗？

【解决方案3】：

我会选择类似的东西：

Users
UserID         int     primary key auto number/identity
UserName       

Questions
QuestionID     int    primary key auto number/identity
QuestionNumber
QuestionText   

Feedback
FeedbackID     int    primary key auto number/identity
QuestionID     int    fk 
UserID         int    fk
Answer
Comment

我会考虑在每个表上放置一个 LastChgDate 和 LastChgID FK 列，甚至可能是 CreateDate 和 CreateUserID。您不需要任何这些表中的特殊列来重新创建插入顺序，自动编号/标识值（虽然并不总是连续的增量）为此工作。

我会避免使用 GUID 和字符串键（如用户名），因为它们会使每个索引占用更多内存。我会使用代理键代替用户名，因为它可能会发生变化（离婚/婚姻/等）。

Feedback 表有点麻烦，是给答案还是 cmets？可能应该是两个表，或者至少有一个 FeedBackType 列和一个文本列。 OP 没有提供足够的信息来完全回答这个问题。即使在 OP 的编辑之后，我也不确定我是否理解：a feedback has multiple questions, so there will be more than one feedback answer

【讨论】：

【解决方案4】：

首先，将用户输入的值作为主键通常是一种不好的做法。例如，如果您必须更改用户名会发生什么？

我个人会选择类似的东西：

User_ID (PK) (GUID)
UserName

Question_ID (PK) (GUID)
QuestionNumber
Question

Feedback_ID (PK) (GUID)
Question_ID (FK)
User_ID (FK)
FeedbackDate
FeedbackText

此外，答案和 cmets 是否相互独立？您可能会考虑有一个 answers 表和一个 cmets 表。

编辑：FeedbackDate 用于订购目的。与保留订单索引相比，它是一种自然的分类器。

【讨论】：

+1 为 PK 提供指导。我使用自然键的每一次体验（我也有过几次）都类似于人类曾经登上绑在探测台上的外星飞船的体验。虽然很容易实现，但当发生任何变化（数据、设计等）时，就会发现问题。
我不会使用 GUID，除非我需要在不同数据库上发生的插入之间进行同步。为什么不是 int？
这更多是出于习惯。它允许不可预见的情况（但它们永远不会发生，对吧？）。说在路上，他们决定扮演“MegaQuestionaire”的角色，他们想合并来自这个来源的数据。使用 GUID 可以最大限度地减少所涉及的工作量。 INT 进行此升级会产生很大的开销。
GUIDS 是一个糟糕的选择，除非您计划复制，因为它们在连接等方面比 int 慢。此外，我发现它们很难进行临时查询，并且您经常需要显示代理 ID，因为文本数据（如人名）不是唯一的，您需要它来识别记录。用户讨厌 GUID，因为它们在出现问题时很难记住和参考。规划不太可能损害系统日常性能的数据迁移（无论如何这可能比简单的数据复制需要更多的工作）不是最佳选择。
啊......可口可乐与百事可乐的古老争论。你的论点是高度主观的，主要是个人喜好。我承认，这对性能有轻微影响，但在许多情况下，这是一个可以忽略不计的问题，有时会让灵活性退居二线。

【解决方案5】：

听起来像是标准化了。反馈问题是 1-1 吗？如果是这样，请确保您对 UserFeedback 表具有唯一约束，其中包括 FeedbackNo 和 QuestionNo。

【讨论】：

反馈表由许多问题组成，因此对问题的反馈将是 many-1 ！在这种情况下我的数据库设计还会有漏洞吗？？
在那种情况下，我会选择 KM 的设计。这对我来说最有意义。我不喜欢可以更改为主键的数据。它还消除了不必要的表格。