Question

我想评价（非常好，好，中等，差...）2个对象：学生和老师。哪种设计方案更好？

解决方案1：

学生（学生ID，评级等）

----------------- 1 --------好-----

----------------- 2 --------为-----

----------------- 3 -----非常好-----


教师（TeacherID，Rating，...）

----------------- 1 -----非常好-----

----------------- 2 --------为-----

----------------- 3 --------为-----

解决方案2：

学生（StudentID，RatingTypeID，...）

----------------- 1 ---------------- 2 ----------

----------------- 2 ---------------- 1 ----------

----------------- 3 ---------------- 3 ----------


教师（TeacherID，RatingTypeID，...）

----------------- 1 ---------------- 1 ----------

----------------- 2 ---------------- 1 ----------

----------------- 3 ---------------- 3 ----------


RatingType（RatingID，RatingDescription，...）

----------------- 1 -------------非常好---------

----------------- 2 ---------------好------------- -

----------------- 3 ----------------为------------ ---

如果两者都不够好，你能给我一些建议吗？谢谢！

Answer 1

解决方案2是这两者中最好的，但是如果你想在你的应用程序生命周期中有多个投票，你应该有一个表格，你可以确定投票的主题是什么，另一个你存储的是投票数：

Student:
   id
   name
   class
   ...

Teacher:
   id
   name
   subject
   ...

voterType
   id 
   description (student or teacher)

contest:
   id
   description (ex: 1st Semester 2013)

contestVotes:
   id
   contestId
   voterType (Teacher or Student)
   voterId
   ratingTypeId

Answer 2

在两个建议的解决方案之间，我肯定会选择第二个解决方案，原因如下：

在涉及订购或汇总的情况下，将Rating存储为数字可以派上用场，在这种情况下，字符串几乎无用。
使Rating列成为RatingType.RatingID的外键强制执行约束，Rating只能包含非常具体的值，具有非常特定的含义。此外，您可能会在将来向RatingType表添加额外的列，为您的评分增加价值。

至于改进建议，既然你问过，请考虑使用IS-A relations来实现这一点。教师和学生显然都是Persons并且在某种程度上具有共同的属性。我将创建一个包含公共属性（即名字，姓氏，地址，电话等）的Person超类表，然后将students和teachers的主键也设为外键。 Persons。

请注意，评级也是一个常见属性。因此，出现在Persons表中是很自然的。除非教师和学生有不同类型的评分，否则你必须实施两个不同的RatingType表。

基于类型的数据库设计

2 个答案: