我正在爲一所學校開設一個特定模塊處理考勤系統的項目。我正在使用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