我正在为一所学校开设一个特定模块处理考勤系统的项目。我正在使用LAMP（PHP 5.2+ MYSQL 5+）堆栈进行开发。现在，学校的实力在1500人左右，每年的工作日总数约为250人。另外，我必须保留5年的记录才能将其删除。学校考勤系统的数据库设计
表结构是
studentId varchar(12)
date date
fn varchar(1) *forenoon*
af varchar(1) *afternoon*
如果我只使用一个表，这意味着1,875,000记录5年的时间。现在，而不是这样一个庞大的数据库，我考虑为每个班级（而不是部分）制作一张桌子。所以考虑到有12个班级，我会有12个表格，这意味着每个表格平均有1,55,000条记录可以管理。
这是正确的做法吗？或者有更好的方法吗？
你在做什么叫做过早的优化。这是一个常见的错误。
你最好是让自己的数据库结构尽可能接近现实，并且在将来如果需要优化或提高速度，你总是可以做到这一点。
从经验和看你的例子，单表解决方案看起来不错。
只要你正确索引你的表列，第一个表不应该有一个大问题。
我不同意将它分解成12个类的想法，因为你不能保证它会留下来的方式（添加类，类合并等）。
弄脏你的数据库规范化效率的感知好处是你应该看看只为极端的情况下（如果有的话）
几点。
你还没有真正提供足够的信息重新链接到其他表和其他什么，如果有的话，这张表将存储。但是你应该从3NF开始，所有表格只有在发现性能问题时才会改变。
我建议不需要将此表分开。如果您为可能需要执行的任何选择性查询创建适当的索引，系统应该能够非常快速地找到所需的行。即使是涉及所有行的分析查询，也有200万个这样的记录只需要一两次扫描，我想这不会造成很大的问题。
MySQL现在还支持将数据分区作为可选功能。分区与您将表分开的建议类似，但它是在物理层完成的，因此用户或开发人员无法使用您的模式进行分区。如果您发现单表实施仍然太慢，这可能是一种有用的方法。 This document提供了MySQL 5.4中分区的概述。
Checksum，
我回应米歇尔认为这是过早优化。
稍后基本上可以提高性能的方法是使用数据库归档和分区功能，以便数据库读取效率更高。我也可以在这个表上建立索引。无论如何，我不相信100万条记录是巨大的。今天的数据库能够处理这么大的数字。你也会遇到性能问题3年现在只有
所以继续写代码，而不是想什么错了！
你为什么称这个巨大的？你有空间限制吗？是否存在性能问题？你是否模拟了这个行数来获得基准？ – 2009-06-20 13:23:39
我很好奇：为什么fn和af有不同的数据类型长度？ – cheduardo 2009-06-20 13:46:29
@cheduardo，对不起，这是一个错字 – Checksum 2009-06-20 14:33:21