作为 MySQL 数据库的多班级、相互关联的学校时间表

发布于 2024-11-03 00:16:05 字数 897 浏览 1 评论 0原文

我现在已经查看了一些与此相关的其他建议,但我所看到的都不太适合我的需求,所以就这样吧!

我拥有的是多班(澳大利亚中学;7-12 年级)、多日(周一至周五)的学校时间表。我现在想要构建的是一个 MySQL 数据库,其中包含要部署在帐户驱动的网站上的以下信息。

  • 主题:
    • 运行时间(如“周三第 1 节”、“周五第 2 节”等 - 此列中的多个值)
    • 教师(链接到所有教师的单独数据库) ) -- 如果教师生病并被替换,则还需要(暂时)改变;可能是“replacementinstructor”列,当为 NULL 时将被忽略。
    • 位置(不同日期的不同但专门分配的房间)--如上所述,当房间更改时临时更改。
    • 其他显而易见的内容:课程名称(“Year 7 Health”)、唯一 ID(类似于“7.HEALTH”,而不仅仅是自动递增 INT。)等。
  • 教师:
    • 名字、姓氏
    • 他们参加的课程
    • 联系信息
    • 其他显而易见的信息:唯一 ID(自动递增 INT)、用户名(fname.lname)、其帐户的密码等。
  • 学生:
    • 名字、姓氏
    • 他们参加的课程(存储为每个学生的单独列表)
    • 年级/表格(7年级、11年级等) .)
    • 基本个人信息(家庭郊区、电子邮件等)
    • 更明显的信息:唯一 ID(与教师相同的设置)、用户名(与教师相同)、密码、等等

任何关于我如何设计这样一个数据结构的见解将不胜感激,我更像是一个 UI 狂热者而不是 MySQL 思想家;-D

提前致谢。

I've looked around for a bit now at other suggestions relating to this, but nothing I've seen has quite suited my needs, so here goes!

What I have is a multi-class (Australian secondary school; Years 7-12), multi-day (Mon-Fri) school timetable. What I now want to build is a MySQL database with the following information to be deployed on an account driven website.

  • Subjects:
    • Running time (as "Period 1 on Wednesday", "Period 2 on Friday", etc. -- multiple values in this column)
    • Instructor (linked to separate database of all teachers) -- This would additionally need to change (temporarily) if a teacher was sick and replaced; perhaps a "replacementinstructor" column to be ignorned when NULL.
    • Location (different, but specifically allocated, rooms on different days) -- As above, change temporarily when room altered.
    • Other obviousnesses: Course name ("Year 7 Health"), Unique ID (Something like "7.HEALTH", rather than just auto-incrementing INT.), etc.
  • Teachers:
    • First name, last name
    • Courses they take
    • Contact info
    • Other obviousnesses: Unique ID (Auto-incrementing INT), Username (fname.lname), Password for their account, etc.
  • Students:
    • First name, last name
    • Courses they attend (stored as an individual list for each student)
    • Year level / Form (Year 7, Year 11, etc.)
    • Basic personal info (Home suburb, email, etc.)
    • More obviousnesses: Unique ID (same setup as teachers), Username (same as teachers), password, etc.

Any insight as to how I might design such a data structure would be greatly appreciated, I'm more of a UI fanatic than a MySQL thinker ;-D

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

笑梦风尘 2024-11-10 00:16:05

我可以想到在 MySQL 中使用以下表格:

学生
学生信息

  • id (auto_increment)
  • 名字
  • 姓氏
  • 用户
  • 名 密码
  • 学生 ID(我有一个学生 ID,但我不记得是在 7 年级还是 10 年级获得的)
  • 年份
  • 电子邮件
  • contact_phone
  • 街道
  • 郊区
  • 州(ENUM - ACT、NSW、WA、南澳州、塔斯马尼亚州、维多利亚州、北领地、昆士兰州)

教师
教师信息

  • ID (auto_increment)
  • 名字
  • 姓氏
  • 职称(博士、女士等)
  • 用户名
  • 密码
  • 电子邮件
  • 联系人电话
  • 街道
  • 郊区
  • 州(ENUM - ACT、NSW、WA、SA、TAS、VIC、NT、QLD)

科目
所有不同的受试者

  • ID(自动增量)
  • 受试者
  • subject_code(例如 7.HEALTH)
  • 年份

地点
学校

  • ID (auto_increment)
  • 位置周围的各个位置(例如 BLOCK A、ROOM 2、MUSIC ROOM)

subject_teachers
每位老师教授哪些科目

  • id (auto_increment)
  • subject_id
  • Teacher_id

subject_students
每个学生选修哪些科目

  • id (auto_increment)
  • subject_id
  • Student_id

subject_timetable
主时间表

  • id (auto_increment)
  • subject_id
  • location_id
  • Teacher_id
  • alt_teacher_id (例如代课老师)
  • 持续
  • 时间 (数字 1 - 一天中有多少个时间段。如果我没记错的话,是 6)
  • 周 (数字 1-2 甚至可能是 1-52)
  • 工作日 (数字1-5)
  • 注释(正如@Oswald建议的那样,您可以在事情发生变化时添加额外的注释)

可以对注释进行整理,然后将其显示为时间表上的脚注。

I can think of the following tables to use in MySQL:

students
Student information

  • id (auto_increment)
  • firstname
  • lastname
  • username
  • password
  • student_id (I had a student ID but I can't remember if I was given this in yr 7 or yr 10)
  • year
  • email
  • contact_phone
  • street
  • suburb
  • state (ENUM - ACT,NSW,WA,SA,TAS,VIC,NT,QLD)

teachers
Teacher information

  • id (auto_increment)
  • firstname
  • lastname
  • title (Dr, Mrs, etc)
  • username
  • password
  • email
  • contact_phone
  • street
  • suburb
  • state (ENUM - ACT,NSW,WA,SA,TAS,VIC,NT,QLD)

subjects
All the different subjects

  • id (auto_increment)
  • subject
  • subject_code (eg 7.HEALTH)
  • year

locations
Various locations around the school

  • id (auto_increment)
  • location (eg BLOCK A, ROOM 2, MUSIC ROOM)

subject_teachers
What subjects each teacher teaches

  • id (auto_increment)
  • subject_id
  • teacher_id

subject_students
Which subjects each student takes

  • id (auto_increment)
  • subject_id
  • student_id

subject_timetable
Main Timetable

  • id (auto_increment)
  • subject_id
  • location_id
  • teacher_id
  • alt_teacher_id (eg substitute teacher)
  • duration
  • period (number 1-however many periods in a day. 6 if I remember correctly)
  • week (number 1-2 or even perhaps 1-52)
  • weekday (number 1-5)
  • notes (as @Oswald suggested you could add additional notes for when things change)

The notes could be collated and then displayed as footnotes on the timetable.

如梦 2024-11-10 00:16:05

显然,您需要一张科目表、一张学生表和一张教师表。

阅读数据库规范化。这将告诉您(除其他外):

  • 不要将运行时间作为逗号分隔列表放入主题表中。相反,使用运行时间表并使用外键将该表中的条目映射到主题表。
  • 将教师映射到课程也是如此。
  • 将学生映射到课程也是如此。
  • 该运行时间表还适合在特定运行时间内保存课程的位置。

此外,如果您在数据库中记录临时更改,则您依赖于人们在特定时间更改相关信息。为了解决这个问题,您可能需要考虑一个表格“课程”,您可以在其中记录

  • “运行时间”
  • “周数”
  • “课程
  • 讲师
  • 位置”
  • “可能特定于该特定课程的其他字段”。

这将允许您提前安排更改(麦卡尼先生在接下来的两周内生病,101 室因重新装修而关闭一个月等)

You will obviously need a table for Subjects, a table for Students and a table for Teachers.

Read up on database normalization. This will tell you (amongst other things):

  • Do not put the running time into the Subject table as a comma separated list. Instead use a table for the running time and use a foreign key to map entries from that table to Subjects table.
  • Same goes for mapping teacher to courses.
  • Same goes for mapping students to courses.
  • That Running Time table would also be suitable for holding the location of a course during a specific running time.

Additionally, if you record temporary changes in the database, you are dependent on people changing the relevant information at a specific time. To get around this, you might want to consider a table Lessons, where you record

  • Running time
  • Week number
  • Course
  • Instructor
  • Location
  • Other fields that might be specific to that particular lesson.

This will allow you to schedule changes in advance (Mr. McCachney is sick for the next two weeks, Room 101 is closed for redecoration for a month, etc.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文