上次發表過一篇資料庫設計後來師傅說理解的不正確就擱置了很久才提筆。關於資料庫的設計是乙個大方面，因為暑假已經用vb6.0敲過機房收費系統了，對於裡面的功能結構也比較熟悉，所以對於重建有很大的幫助。
分析er圖：
實體user和card之間存在著4種關係：註冊、充值、取消、上下機。
實體card和student存在屬於的關係：每個學生都至多可以有乙個卡。
實體user和basicdata之間是唯一確定的關係1:1，記錄中字段是唯一對應的。
實體user和worklog是1：n關係，每個使用者有多個工作記錄。
實體user和account是1：n關係，使用者可以進行多次結賬操作。
這次和以往表的不同在於
1.增加了卡表t_cardinfo：因為原表是把卡表和學生表混合使用，但是我們在查詢過程中大部分是分離開來增刪改查的。同時把兩個表裡的字段進行分離。
2.合併正在工作表t_onworkinfo和t_worklog表：這兩個表基本內容相同，只需要在t_worklog中進行改動即可。
同理合併t_onlineinfo和t_lineinfo表。
3.合併日結賬單和周結賬單為t_accountinfo：表裡內容完全相同就是查詢的時候查詢條件不同而已。
因為是小型範圍內使用可以把兩個表進行合併如果是大型系統就必須分開，否則在查詢的時候效率就會降低。
注意：在資料庫中設定外來鍵，把兩個表聯絡起來。
其實我們建立資料庫的時候重要的是知道她為什麼要建立，要如何在系統中運用，從根本上解決問題。理清關係很重要。
如：userid之所以要和很多表都建立起來聯絡是因為我們的每乙個註冊或是充值的操作都要落實到人，其實也就是錢的問題，如果出了問題找哪個責任人，需要在資料庫中體現。
如：status和ischeck，從我們開始註冊到取消註冊期間都是使用狀態，一旦真的取消就是不使用狀態了，但是ischeck表示的是在你「使用」期間，一旦上機就是未結賬狀態，下機就是結賬狀態，這個和我們在電子閱覽室上機是乙個道理。
如：我們在card和user實體之間是m:n的關係，因為乙個卡可以多次被不同使用者修改狀態，「使用」和「未使用」，乙個使用者當然也可以修改多個卡狀態，這個也是經過好久才理清的。
小結：其實網上有很多機房收費的er圖，但是重要的是自己的理解，每個人都有自己的畫法，只要可以把自己說服就好了。
sql server 資料庫設計《機房重構》
開始機房重構了，不自己設計乙個資料庫怎麼好意思說自己是在重構機房呢？而且原資料庫本身就有很多瑕疵，不符合資料庫的規範，今天我們就根據資料庫三正規化，來設計屬於我們自己的一版資料庫。本次的資料庫是為了服務於我們的機房收費系統，機房收費系統大致的要求是什麼呢？看圖 這是我們機房收費系統的主要的功能，這涉...
重構機房收費系統 資料庫設計
弄完了三層的例子後，機房重構早就該開始了，但是自己一直不想動，萬事開頭難，機房收費的重構，先是資料庫的設計問題，開始包括er圖的設計。然後設計資料庫，設計表.現在想想自己資料庫的設計。首先先想一想上下機的整個流程，乙個學生拿著卡來到老師面前，老師講學生的卡啟用，學生在拿著卡去找機子上機，假如學生沒有...
機房重構總結之路 需求分析和資料庫設計
機房總算做完了，但是還需要乙個系統的總結過程，現在我的總結之路開始了！一 需求分析 做軟體首要的就是做需求分析，因為是第二次做機房，所以對於需求這一塊還是比較了解的。下面我們來分析一下我們的機房 1.機房收費系統使用者是 機房的老師，學生。2.機房收費系統的主要功能 學生 修改密碼，查詢充值記錄，檢...