Question

假设我们进行了一项调查，其中跨多个实体提出了一些问题。

例如：
汽车品牌= [品牌1，品牌2，品牌3，品牌4 ...]

将针对每个汽车品牌（循环播放）询问此问题。
问题Q01 =（比例1-10）您认为[汽车品牌]汽车可靠吗？
问题Q02 =（比例1-10）您认为[汽车品牌]汽车是否物有所值？
...

我正在设计一种架构，该架构将支持一些基于Web的分析工具，因此查询性能非常重要。

该架构将是3个表：记录，问题，答案

我对答案表有两种方法：

A）表格：答案

cors

B）表格：答案

QuestionId | AnswerValue | BrandOption 
   Q01     |      7      |      1
   Q01     |      5      |      2
   Q01     |      4      |      3
   Q01     |      8      |      4

查询可以一次查询一个品牌，也可以查询所有品牌，两个查询的优先级相同。

如果我需要做类似分组的操作，那么选项A似乎可以给我带来一些好处，但是，如果大多数查询都针对某个特定品牌，那么选项B似乎更有效。

有想法吗？

Answer 1

即使您现在看不到选项A，它也更好。
从任何角度看，在一个数据库“单元”中存储多个值都是一个错误（尽管不幸的是，这是一个非常常见的错误），更不用说它违反了first normal form，它特别指出每一列都可以每行仅包含一个原子值（尽管原始规则使用了不同的术语）。

缺点很多，其中一些很关键，包括（但不限于）：

您失去了使用正确数据类型的能力-存储在一起的两个int必须存储为与int不同的数据类型。
您可能会失去验证数据是否正确的能力，或者将不同部分转换为正确的数据类型的能力（当今大多数数据库都支持检查约束，但并非全部都支持（是，MySql，用我的手指指着你！））
您失去了分别对数据各部分强制唯一性的能力。
您不能使用数据的不同部分作为外键约束的基础

这个列表一直在不断-但是我认为任何人现在都应该得到这张照片-应该使用数据库列为每行存储一个值-每次。

Answer 2

我认为第一个版本更可取。这样可以更轻松地查找单个品牌的不同问题的答案，以及跨品牌的相同问题的答案。

缺少问题ID似乎是一个不好的替代品。一方面，它排除了与questions表和brands表的简单外键关系。我是明确的外键关系的忠实拥护者。

当然，要使此工作有效，您将需要一种方法来存储“无品牌”或“无品牌”。一种方法是使用NULL这样的答案。

SQL-调查数据，用于循环调查问题的表架构设计

2 个答案: