機房收費系統的資料庫設計

這次機房收費系統的資料庫設計與上一次有很大不同,之所以會引起不同,是因為遵循了資料庫設計第三正規化。

什麼是資料庫設計第三正規化在我以前的文章中有所體現，《資料庫設計第三正規化》

我們先來看看前後的不同之處：

第一次共有10張表：結賬資訊，基本資料，上下機記錄，退卡資訊，正在上機資訊，正在工作老師資訊，

充值記錄，學生資訊，使用者資訊，工作記錄。

而第二次，精簡到了9張表：

合併正在上機資訊表和上下機記錄表，合併了正在值班老師資訊表和工作記錄表，將學生資訊表分為學生基本資訊表和上機卡資訊表

減少了冗餘資訊。

到底怎麼減少了冗餘資訊，舉個例子：

原來的上下機記錄字段包括：

序號，卡號，學號，學生姓名，學院，年級，性別，上機日期，上機時間，下機日期，下機時間，消費時間，消費金額，餘額，卡狀態，機器號

學生資訊包括：

學號，姓名，卡號，學院，年級，性別，餘額，操作員，卡狀態，是否結賬，註冊日期，註冊時間

正在上機資訊表字段包括：卡號，學號，學生姓名，學院，年級，性別，上機日期，上機時間，機器號

我們看到：

序號，卡號，學號，學生姓名，學院，年級，性別這些資訊是重複的，而且學生資訊中，學生資訊和上機卡資訊是混合在一起的。這些明顯不符合資料庫設計第三正規化。

在本次資料庫設計中，

正在上機資訊表和上下機記錄表合併為上下機記錄表，包括字段：

卡號，上機日期，上機時間，下機日期，下機時間，消費時間，消費金額，操作員，機器號，卡狀態，是否結賬

將學生資訊分解為卡資訊和學生資訊

卡資訊表字段：卡號，註冊日期，註冊時間，學號，餘額，操作員，是否結賬，卡狀態

學生資訊表字段：學號，姓名，學院，年級，班級，性別

對比兩次設計，我們明顯可以看到，減少了資料冗餘，學生表和卡資訊表之間有外來鍵約束，而卡資訊與上下機記錄是一對多的關係。如果以後機房收費系統的學生資訊要和教務系統的學生資訊掛鉤，那麼只需替換掉學生資訊一張表就可以搞定。反觀第一種設計，會發現，整個資料庫設計必須重新推倒

事物往往具有多面性，設計正規化也會帶來一定的麻煩：操作查詢困難，因為需要聯絡多個表才能得到所需要資料，而且正規化越高效能就會越差。

打個比方：查詢上下機記錄需要顯示，學號，卡號，學生姓名，上下機資訊相關字段。

第一次的設計，只需要查詢一張表就可以搞定

而遵循資料庫第三正規化的設計，卻要查詢三張表。

所以使用多高的正規化需要權衡利弊，一般在專案中，使用到第三正規化也就足夠了，效能好而且方便管理資料。

機房收費系統的資料庫設計

這次機房收費系統的資料庫設計與上一次有很大不同,之所以會引起不同,是因為遵循了資料庫設計第三正規化。什麼是資料庫設計第三正規化在我以前的文章中有所體現，資料庫設計第三正規化 我們先來看看前後的不同之處 第一次共有10張表 結賬資訊，基本資料，上下機記錄，退卡資訊，正在上機資訊，正在工作老師資訊，充值...

機房收費系統的資料庫設計

這次機房收費系統的資料庫設計與上一次有很大不同,之所以會引起不同,是因為遵循了資料庫設計第三正規化。什麼是資料庫設計第三正規化在我以前的文章中有所體現，資料庫設計第三正規化 我們先來看看前後的不同之處 第一次共有10張表 結賬資訊，基本資料，上下機記錄，退卡資訊，正在上機資訊，正在工作老師資訊，充值...

重構機房收費系統 資料庫設計

弄完了三層的例子後，機房重構早就該開始了，但是自己一直不想動，萬事開頭難，機房收費的重構，先是資料庫的設計問題，開始包括er圖的設計。然後設計資料庫，設計表.現在想想自己資料庫的設計。首先先想一想上下機的整個流程，乙個學生拿著卡來到老師面前，老師講學生的卡啟用，學生在拿著卡去找機子上機，假如學生沒有...