问设计一个可扩展的大学数据库模式

EN

初始响应

一些初步事项：

• 作为一个实际问题，我发现为创建/修改时间添加日期字段是有帮助的；它使您在调试数据问题时更加容易。几乎所有不是查找表的表都会从中受益。如果表只写一次，请考虑前面修改的时间列。
• 确保您没有将密码存储在明文中。这超出了这个问题的范围，但我想我还是花点时间提一下吧。

尽管如此，我认为在您真正得到一些数据来支持您的问题之前，您还在过早地担心诸如可伸缩性之类的事情。话虽如此，我确实有一个简单的建议。

如果一门课是40节课，那么每节课记录一门课的出勤率几乎需要80*40=3200记录，那么每学期多出6门课怎么样？

的确，你增加了很多记录，但到目前为止那些记录看起来是.每个10字节？我不打算查找数据类型的大小，但您不会用10字节行拆分银行。我怀疑，虽然用户总是希望有出勤，但它很可能，同意保留政策，可以帮助你限制增长，并允许你修剪过去几年的出勤记录。

不过，你还有优化的余地。与其在一对一的关系中记录每个Student的出勤率，我建议你通过选择较小的“出席”或“错过”记录来记录出勤情况。例如，如果你假设大多数学生去上课，你会选择“错过”，这意味着Attendance表将只有Students谁错过了讲座行。如果一个Student在Attendance桌子上有一排，他错过了讲座，否则他就会在场。当然，在这种情况下，应该将Attendance重命名为类似Absence之类的东西。

当涉众想要向架构中添加更多数据时，请花更多的时间考虑您可能做的事情。例如添加类别或分组、别名或次要名称或次要电子邮件。

关于动态表生成的

哪些表应该保留为应该只创建一次，哪些表应该动态地创建，以及在什么时间间隔？每年/学期/任何其他建议

这是一个过早的关注，因为你还不知道你的性能问题是什么。我倾向于在发布后查找性能不佳的表，并根据您的需要建立一个归档过程。

我不建议动态创建表，因为您必须对影响应用程序的活动主机上的数据库模式进行编辑，如果提交错误，应用程序就有可能导致应用程序崩溃。要回答您的问题，我建议在行级别存档数据。

如果您需要高可用性但很少访问旧数据，您可以使用应用程序的一个单独模块来显示它，并使用它自己的单独数据库。此数据库可以由外部进程填充，该进程将行(在维护窗口期间)从活动/活动模块移动到存档模块。

如果您不需要它是高度可用的，您可以将行从活动数据库(在维护窗口期间)导出到压缩存档中，该压缩存档可以正确备份，并且可以使用开发人员工具按需查看。

这种方法的好处是，您的行操作不会破坏站点；最糟糕的情况是，一些数据丢失了一段时间，或者性能下降了。

作为首席开发人员，应该由您来决定需求是什么，并采取相应的行动。再次，我建议你停止这种工作，直到你有一个具体的问题。