Question

所以，昨天我问了两个围绕同一个想法的问题：重新组织A-未正常化的数据库，而B-由于我的无知而变得一团糟。我花了大部分时间来组织我的想法，阅读并完成一些测试。今天我想我对DB的外观和行为有了更好的了解，但我想确保理解正确的SQL DB设计和规范化过程的核心思想。

最初，我有一个名为“文件”的表，其中包含有关文件的数据（它的URL，上传日期，上传日期的用户ID等）以及一个名为“成绩”的列，代表您可能的年级使用该文件。（仅供参考：这些文件是学校的课程计划）我意识到我违反了关于规范化的规则＃1 - 我正在存储我的“等级”，如“1,2”或“2,6”或“3,5,6” “在一栏中。如果我想看JUST三年级课程或者只读五年级课程，这会在尝试解析数据时引起严重的麻烦。

向我建议的内容以及后来显而易见的是我有3张桌子：

文件（有关文件，网址等的数据）成绩（可用年级水平表。可能1-6级开始） files_grades（联结表）

这是有道理的。我只想确保在做之前明白我在做什么。假设用户A上传文件xyz并确定它对2年级和3年级有用。

我会在“files”表中写一条记录，其中包含有关该文件的数据（kb大小，url，描述，名称，主键files_id）。让我们说它得到了id 345.

由于成绩选项数量有限，成绩可能与其成绩相当（即1年级为成绩_ 1，2年级为成绩_ 2）

然后我将两条记录写入包含

的“files_grade”联结表

files_grade_id，files_id和grades_id，即

1,345,2

1,345,3

表示files_id 345适合的2个等级。然后我挥动我的魔法SELECT和JOIN棒并拉出我需要的数据。

这有意义吗？我是否再次误解了关系型多对多数据库的正确结构？

问题2刚刚出现在我身上：因此，课程可以有多个“等级”。没问题，我们刚刚解决了（我希望！）。但理论上它可以有多个“学校” - 小学，中学，高中。如果文件条目中等，高等级为1,2，我们该怎么办？这可以很容易地通过说“每个文件一个学校，用户！”来解决，但我喜欢把它扔出去。

Answer 1

然后我将两条记录写入包含
的“files_grade”联结表
files_grade_id，files_id和grades_id，即

files_grade_id 这里是多余的，因为 files_id 和 grades_id 的组合已经是唯一的（因此可以设置为主键）。

但理论上它可以有多个“学校” - 小学，中学，高中。如果文件条目中等，高等级为1,2，我们该怎么办？

根据您的要求，您可以将这些存储为以前成绩的“延续”，例如： 1-6小学，7-9中，10-12高。然后你可以完全没有成绩表（因为你可以将这些数字存储在 files_grade 表中）。

Answer 2

从它的声音来看，听起来不错。但有一点是：你不需要为桥表（FILES_GRADES）提供ID，如果这样做，则需要增加ID。

你会有一个由两部分组成的主键：grade_id和file_id，files_grade_id只会使事情变得复杂，并且会产生错误的索引，因为你从不在选择中使用它。

Answer 3

由于您的第一个问题已经得到解答，我将对第二个问题进行一次尝试。

有多种方法可以做到这一点，但有一种可能性是为“学校”添加另一个表并将其作为联结表的一部分包含在内 - 当然重命名联结表以匹配新设计。所以，你可以：

School Table:

-------------------------
  SchoolId  |   School  
-------------------------
     1      | Elementary
     2      | Middle
     3      | High
-------------------------

Files_grades_school

------------------------------------
  FileId  |   GradeId  |  SchoolId 
------------------------------------
    345   |      1     |      1
    345   |      1     |      2

您可能希望根据使用模式创建多个索引。

这个数据库结构是否正确，正确并规范化？

3 个答案: