该系统必须管理学生,教师,员工和等级。这是用于生产,而不是学校的作业。因此,请让我知道我是否可以在任何方面进行改进。 :)

我主要关心的是自动化。我希望我的软件无论我是否仍然可以运行。

我正在使用SQLite作为数据库: br />

评论

确定要使用sqlite吗?您期望并发用户数量是多少(读和写)?每个表中预期的行数是多少?您将如何处理审核跟踪,删除/取消删除,编辑/撤消?不要将密码存储为纯文本。预先知道您将要运行哪种报告?对于教职员工和学生来说,很明显,您将需要不时调整字段;在那里提出通用的可扩展性机制可能是值得的。

并发用户:2.每个表最多具有500万行,这确实是在扩展它。

我建议将所有不应包含NULL值的列设置为“ non null”。

我现在没有时间进行全面审查,但是除了下面我看到的那些以外,我还想提供一个简短的注释:我觉得在各个表中看到的“观察”可能会受益于每个表的单独存储(即:StudentObservations )(带有时间戳),也可能需要用户审核。总的来说,我认为用户角色(对于哪些人/他们可以更改和不能更改的角色)对于学校来说也非常重要,尽管这听起来像是一个很小的设置。

#1 楼

立刻让我惊讶的一件事是:

LastNameFather string,
LastNameMother string,
FatherName string,
MotherName string,
FatherContact string,
MotherContact string,
FatherPlaceOfWork string,
MotherPlaceOfWork string,


您的设计假设每个学生将只有一个母亲和一个父亲。我现在可以告诉你,情况并非如此。父母离异的学生可能有两个母亲和两个父亲,他们都希望列出他们的联系信息。有些学生可能有同性恋父母,因此有两个父亲或两个母亲。有些学生可能既没有父母,又没有父母的法定监护人。

解决这个问题的一种方法是为“人”建立一张桌子,并将人与每个人联系起来。学生。标识该人是父亲还是母亲(或非父母监护人)。这也将简化兄弟姐妹的关系:您可以为多个学生拥有相同的母亲,父亲等。

对于大多数学生来说,这不是问题,但对于您可能想不到的更多问题,这将是一个问题。轻松处理各种家庭情况,对那些家庭和您的管理人员有所帮助!

评论


\ $ \ begingroup \ $
在下一次迭代中,我会牢记这一点。我将创建一个表“ Guardian”,其中包含IDStudent,IDGuardianType(父母,监护人等)以及姓名,联系方式等。
\ $ \ endgroup \ $
–塞尔吉奥·塔皮亚(Sergio Tapia)
2011-1-30 14:49

\ $ \ begingroup \ $
请记住,孩子的出生证上可能会有两个母亲或两个父亲。
\ $ \ endgroup \ $
–doppelgreener
2011年1月30日17:11

\ $ \ begingroup \ $
请注意,并非所有人都适合提议的整洁的firstname + lastname模式。对于学生来说,这可能就足够了,但他们的父母不太可能全部来自当地文化。
\ $ \ endgroup \ $
– Toby Speight
19年3月13日在15:20

#2 楼

跳出来的一些事情

采纳了马丁·约克的建议,并尽可能保持一致,用户为每个表标识诸如user_id之类的主键名,而不是id,因为这将使编写/维护SQL。对于外键,我建议先表格area_idIdArea相比,因为它在自然语言中的流动性更好。应该尽可能地努力)
使用适当的字段类型,看起来您在使用字符串很多,例如聘用日期应该是实际的时间戳记/日期时间列,性别可以是枚举,等等。
职员表和学生表中的联系人/电话信息可以放在更合适的电话/联系人表中,因为它们是一对多的关系。
您的出勤表...看起来要么表明学生就读特定一天还是不一天...看起来像这样在每个班级都会更多,因为一个学生可以参加半天等等。
如果一个员工有一个以上的员工类型,是否有可能因此您应该有一个关联表将员工与员工类型相关联
代替员工多年的服务,您能不只是使用雇用日期列来计算出来,而不是每年更新服务年份列。

我注意到了一些东西,希望对您有所帮助。

#3 楼

注释


您所有的ID(唯一ID)都称为ID(可以,并且对您有用)
但是我发现当您开始进行联接时,这可能会变得很难读书。因此,我想在表后命名唯一键。例如,用户表上的User_ID等。
为了使标识符更易于阅读,可以使用驼峰式大写字母或带有_
的单独单词。因此,IDAreaIdAreaID_Area(请记住要选择一种样式并保持一致)。保持人们的信息。然后,一个用于保持人与人之间关系的关系表。这样,当您的数据库扩展时(在业务环境中会发生这种情况),您可以表达职员之间的其他关系。
与职员有关。像职员一样,我会将“学生”的个人详细信息保留在“人”表中。注意。我仍将为Staff / Student保留一个单独的表(或视图),该表具有指向Person表的链接。


评论


\ $ \ begingroup \ $
关于第一点,我使用实体框架,因此在我的代码中输入:.FindAllStudents()。Where(s => s.ID == parameterID);像那样。 :P
\ $ \ endgroup \ $
–塞尔吉奥·塔皮亚(Sergio Tapia)
2011年1月29日17:22

\ $ \ begingroup \ $
第一点是摆动和回旋处。如果您始终调用主键ID,那么您就会知道ID始终是主键-由于存在一些配置上的好处,因此可以抵消潜在的SQL问题(尽管我建议tableID = table.ID很清楚) )
\ $ \ endgroup \ $
–墨菲
2011年1月31日18:21

\ $ \ begingroup \ $
@Murph:这是一个代码审查,所有观点都是主观的。在简单查询中,ID就可以了。但是,一旦您开始编写复杂的多个嵌套查询(在现实世界中会发生这种情况),它们超出了2个三页,那么额外的清晰度实际上会让您受益匪浅。
\ $ \ endgroup \ $
–马丁·约克
2011年1月31日19:02

\ $ \ begingroup \ $
一切都是妥协,您放弃一件事而获得另一件事。而且我已经完成了复杂的查询(-:
\ $ \ endgroup \ $
–墨菲
2011年1月31日19:25

#4 楼

我同意上面提到的所有其他观点,但是我会谈谈几点:在某些地方,这可能归结为一个有意识的决定,即没有完全规范化(可能由于某些原因而不是……取决于您的问题空间),但是总的来说,当我开始看到相同的字段名称出现在多个表中时(除了PK / FK关系),我变得可疑。所有“人”字段都是一个示例(马丁·约克(Martin York)谈到,但我将进一步介绍)。注意“职员”表和“学生”表之间关于母亲/父亲/工作场所/职业的重复程度。父母都是人。员工也是人。学生是人。
我注意到您的学生表中有一个“观察”字段。我强烈建议您使用带有以下字段的“学生”表外键来定义“观察”表(Staff_ID用于记录观察者)。随着时间的流逝,观察值将不断累积,了解何时以及由谁创建观察值将很有帮助: br />我同意应该有一个单独的“ Contact_Info”表的概念。此外,我敢打赌,您可能希望不时向学生(或学生的父母)发送邮件。为此,我将包括一个“地址”表。我不会假装不知道它在玻利维亚的运作方式,但是在美国,学校喜欢寄出成绩单(尽管这些天,父母也可以通过互联网跟踪学生的学习进度……)。
工作人员的工资可以改变。尽管您可以决定覆盖该值是可以接受的,但这是另一个区域,其中正确的规范化指示了Staff-Salaries表,该表包括ID,Salary和Effective_Date字段。

您可能需要花多长时间才能完成标准化过程,但要注意一个或多个其他评论者,您应该始终拍摄3NF。根据我自己的痛苦经历,我向您保证,当您的老板决定他要一份显示员工工资在五年内增加的报告时,您会很高兴的。

尽管经常会发生基于设计的有意识的决策来对表进行“非规范化”,但该决策应记录在案,以备日后可能需要维护数据库的人员使用不再在那里。

希望有帮助!

#5 楼

我感谢您为表和字段选择的所有名称都是可以理解的,并且不言自明。只有“ GradeParalelo”对我来说没有意义。

但是,我建议添加简短的注释来描述字段和表。包括需要复杂思考的设计决策动机,尤其是如果您希望系统由不同的人来维护。

评论


\ $ \ begingroup \ $
这是因为它在Spanglish:P中基本上,在玻利维亚,您可以拥有许多年级的“实例”。一个学生属于一个年级的一个实例。
\ $ \ endgroup \ $
–塞尔吉奥·塔皮亚(Sergio Tapia)
11年1月29日在18:07

#6 楼

似乎有重复,我只是将每个表的更改放在单独的答案中。

员工表和父亲的联系信息可以放在一个单独的表中。这样,如果某人具有不同的联系人,您就不会受到局限。就像老师可以当教练一样吗?如果是这样,则必须更改表。所有类型都有专业吗?
关于DateOfHiringYearsOfService,可以使用当前日期和DateOfHiring来推定服务时间。
我没有办法停用工作人员。当它们终止时会发生什么?放弃他们的记录不是一个好的解决方案。您可能需要考虑在表格中添加终止日期。


#7 楼

所有表都使用自动分配的序列作为键,这不是正确的数据建模。许多人这样做,却忘记了实际/业务/现实世界的主键。您不想允许多个具有相同名称的用户/区域/主题,因此必须在User.usernameArea.nameSubject.nameSubject.Abbreviation等上添加唯一约束。它从未使用过/未引用,逻辑键是ID

SubjectGrade类似:IDGrade,IDSubject代替ScoreRecord