考勤数据库的良好数据库设计（模式）是什么？ [关闭]答案

【问题标题】：What is a good database design (schema) for a attendance database? [closed]考勤数据库的良好数据库设计（模式）是什么？ [关闭]
【发布时间】：2010-10-15 05:43:21
【问题描述】：

我正在尝试为亲戚的武术工作室申请保持出勤率。我试着四处寻找一些类似的例子，但我找不到任何具体或足够清晰的例子来用于这种应用程序。

目前，我正在使用两张表，一张用于保存学生信息，students(id, first_name, last_name, email, ...)，另一张用于记录一年中每周的出勤率，出勤率(id,周_1，周_2，周_3，...）。我正在尝试将其更改为按天保持出勤率，但似乎想不出一个好的方法，因为我对 MySQL 还是有点陌生。

我正在努力做到这一点，以便可以以类似日历的格式查看出勤情况。只制作 365 天的列可能会很糟糕......并且每个月都有一个表格。我注意到一些类似的应用程序只是跟踪日期，并将其存储在数据库中。这种方法会更好吗？或者，还有其他更好的方法来设计这种数据库吗？提前致谢。

【问题讨论】：

标签： mysql database-design

【解决方案1】：

在武术中，教练也是学生——所以Instructor 表是Student 表的子类型。所有常用字段都在 Student 表中，只有特定于教师的列在 Instructor 表中。

Art 表列出了学校提供的艺术（柔道、空手道……）。

学校可能有几个房间，这些都列在Room 表中。

ClassSchedule 描述了学校提供的已公布的课程表。

出勤记录在Attendance 表中。

Calendar 表中的一行是一个日历日（日期）。该表具有日期属性，如DayOfWeek、MonthName、MonthNumberInYear 等。

TimeTable 中的一行是一天中的一分钟，例如 7:05。

日历和时间表允许按日期/时间轻松报告出勤率，例如

-- Attendance of judo morning classes
-- for the first three months of the year 2010
-- by day of a week (Sun, Mon, Tue, ..)
select
    DayOfWeek
  , count(1) as Students
from ClassSchedule as a
join Calendar      as b on b.CalendarId = a.CalendarId
join TimeTable     as c on c.TimeID     = a.StartTimeId
join Attendance    as d on d.ClassId    = a.ClassID
join Art           as e on e.ArtId      = a.ArtID
where ArtName = 'judo'
  and Year    = 2010
  and MonthNumberInYear between 1 and 3
  and PartOfDay = 'morning'
group by DayOfWeek ;

希望这能让你开始。

【讨论】：

日期表是一种数据仓库技术。对于一个承认自己对 mySQL 非常陌生的人来说，这可能非常令人困惑。当普通的日期列在事务数据库中就可以了时，我强烈建议不要使用日历维度。
还有一个时间维度……你到底想对这个新手做什么？
@Stephanie -- 那么，你对 Daniel 了解多少，是什么让你认为他无法理解这一点？
@Stephanie -- 没错，ClassSchedule 表中的日期时间列会很好。使用 Calendar 和 TimeTable 只是一种从查询的 WHERE 子句中删除日期和时间函数的技术，并且在数据仓库中经常使用。
@Deepak 还有...？该表的 1000 万行约为 0.2 GB（包括索引）。

【解决方案2】：

出席应该有 id、student_id 和 date。这是学生参加时您需要记录的所有内容。如果您想知道在特定日期参加了多少学生（以及谁），您可以针对该特定日期或日期范围运行查询。

您还可以创建一个课程表，在这种情况下，出勤表将是 id、student_id 和 course_id 课桌可能是 id，hold_on_date

除非您需要在课程表中添加更多列，否则我认为这是矫枉过正。

【讨论】：

【解决方案3】：

退一步，你有两种类型的实体：

一个人[像一个学生]
事件 [像一个班级]

将任何实体视为存在于现实世界中的事物。

还有一种关系

出席

关系就是实体之间的关联，并且通常具有与之关联的时间数据或其他类型的度量。

所以不用想太多，你应该有3个数据库表：

与会者 [E]
类 [E]
出席[R]

E = 实体，R = 关系

如果您发现自己在其中一个实体表中复制数据，这是一个好兆头，表明该实体需要“子模型”。在某些地方，这被称为“不要重复自己”或 DRY，而对于实体关系建模，这被称为“数据规范化”。

请记住，构建更精细的架构需要花费时间和代码。因此，请考虑从简单的 [3 个表] 开始并重构冗余。

【讨论】：