做web開發離不開資料庫的設計，一般的小專案資料庫多數要自己設計的。最近的乙個專案除了介面由美工來做之外，其餘全是自己完成的。
專案完成後開始的時候還順利，因為訪問量不是很大，沒出現什麼問題。但沒過多久，日誌中的錯誤就頻繁出現，而且經常是同樣的錯誤，資料庫也有大量死鎖。有問題當然要想辦法解決，所有我把更多的東西cache起來，開始的時候直接用的是asp.net中的cache物件，由於一開始沒有統一的計畫，所以cache的東西就有點亂。一段時候之後，程式錯誤的問題依舊存在，由是我想到了資料庫設計問題，由於專案一開始的時候疏忽了一塊功能上的設計，自己也沒在意，這塊功能是在測試的時候加上去的，所以有很多不合理的地方。比如，取使用者的一些狀態值的時候都是通過實時統計的方法讀取，雖然資料沒問題，但當記錄很多的時候，而統計一般比較費時，所以會出現死鎖等問題。
通過一段時候的觀察和考慮之後，自己想出了解決方案，一是要把cache層分離出來，並重新整理cache。二是把幾個統計字段新增到使用者表中，讀的時候不再實時統計，當然代價是要維護這些統計值。
經過這兩步改造之後，目前程式執行還正常。自己從中學習到的對資料庫設計的經驗我想對我來說很寶貴。表設計時，加一些統計值，比實時去統計要好得多。雖然這可能產生一些資料不同步的問題，這個問題可以加另外的作業來同步資料，總比程式慢並不穩定來得好。
記錄一下自己的一些想法。總比什麼沒有好。
對IBatis的Cache設計的一點看法
前兩天，又看了一下原作 ibatis in action 對快取 cache 一節又仔細閱讀了一次，感覺 ibatis 的 cache 設計有點雞肋的感覺，企業級應用基本不會採用。b 1.快取什麼？b 書中寫道，一般orm框架，如hibernate等，採用物件快取，而ibatis採用的是簡單查詢快取...
資料庫主鍵設計的一點思考
今天做畢業 涉及到資料庫表的設計問題,是乙個簡單的網上訂票系統 jsp sql server2000 要求同乙個人 在同一天同一車次只能訂一次票.於是把 姓名,手機,發車日期,車次,數量,發站,到站,席別,票種,有效證件,證件類 別,取票地點 中的姓名發車日期 車次 定義為組合主鍵,不知道有沒有更合...
對設計一點感觸
今天，稍微參悟了下 spring框架。裡面提到了 3種類 物件解耦的方式 介面注入 setter注入 構造注入 前一種 比較傾向與純物件導向的設計思想，主要通過介面來實現類 物件兩兩之間的耦合問題。在真正實現方案時，比較偏向於應用設計模式來解決一切物件之間的問題，對反射應用不是很多。後兩種 比較傾向...