Question

注意：我看过一些关于类似问题的相关问题;但是，他们都没有完全回答我的问题。

我有学校的考试数据。我的数据集中有大约500所学校和大约12门科目考试（每所学校都有每个考试的数据）。每个考试有6个属性（列）。将初始数据加载到数据库后，不需要进行任何修改。关于SELECT查询，我认为单独的考试数据经常被用作对多个考试的查询。但是，数据库将由可视化数据的网站使用，因此可能必须经常运行那些SELECT查询。考虑到这一点，我可以想出组织这些数据的三种方式，每种方式都可以产生（显然）BCNF表。

第一种情况：

school
exam1_attr1
exam1_attr2
...
exam12_attr6

这个架构感觉不对，但我没有强烈反对它的论据。正如我所说，我的数据不会改变，因此将考试刻入属性名称并不是一个大问题。但是，这样的设置会在整个数据集上造成一些聚合困难（即，结果查询可能会不必要地复杂化）。

第二个架构：

school
examID
attr1
attr2
...
attr6

虽然这个架构看起来很有吸引力，但我发现很难说服自己，将考试表示为值而不是列或单独的表是一个好主意。也就是说，这组考试是已知的，有限的和最终的，并且每个考试具有完全相同的属性 - 听起来像是单独表格的主要候选者。另一方面，在这样的安排下，聚合和单一考试的查询都非常干净和直接。

对于12个单独的考试表，第三个模式将是相同的：

school
attr1
attr2
...
attr6

从概念上讲，我觉得这个模式最能代表我的数据：每个考试在逻辑上都分成了自己的表。但是，任何需要在所有考试中汇总数据的查询都会包含12个表格，这让我感到非常不安。

因此，我的问题是：在我的情况下哪种数据库设计最好？虽然我正在寻找答案，但我对选择一种模式而不是另一种模式的原因也很感兴趣。具体来说，我想知道：

运行查询的效率如何随每个数据库设计而变化，
现实生活中的重要性是编写查询的难易程度（假设数据主要由网站使用 - 我很少在网站完成后对数据进行查询），
如果考虑到对网站数据的潜在未来变化，哪种设计会更好，
如果学校数量不是500，而是50,000，那么你的答案是否会有所不同。

简而言之，我对任何可以帮助我理解为什么一个设计比另一个更好的意见感兴趣。任何数据库设计理论也是受欢迎的。谢谢！

Answer 1

在操作关系数据库中，更改速度比选择速度更重要。在数据仓库中，选择的速度比变化的速度更重要。

您有一个数据仓库。

操作关系数据库为normalized。

数据仓库使用star schema的一些变体。

出于您所说的原因，您的第二个架构是一个很好的架构。聚合和单一检查查询都非常干净和直接。但是，您应将学校信息放在单独的学校表中，并将学校表ID（主键字段，自动增量整数）作为考试表中的外键引用。这使您可以更轻松地从500到50,000所学校扩展。

关系数据库设计：一个表中的标准行值与单独的表

1 个答案: