11資料庫中表結構的變更總是一件讓人感覺不舒服的事情。
在新增加字段時，如何對以前的操作不產生影響或者將影響降至最低呢？
一種方法：直接在表上增加乙個字段，給該字段設定乙個預設值，該預設值用於標記以前的資料，然後用新的值來標記以後的資料。
如果說是標記的話，那麼為什麼不在設計的時候就專門建立乙個字段，來作為資料的版本標識呢？
但是問題好像沒有這麼簡單，比如：在his系統的設計中，有關科室人員的設計，在最基礎的版本中，只需要有科室人員的姓名，登陸密碼，編號，所屬科室等資訊就夠了。但是如果醫院領導要求在更大的範圍內對醫院進行資訊話的管理，那麼在科室人員資料的設計上，就要再增加新的內容，比如：出生日期，家庭住址，學歷，職稱，是否是黨員等等，這些資料該如何處理呢？是重新設計資料庫嗎？
在設計資料庫的時候，裡面的資料流程也是資料的生長軌跡，可否專門對生長軌跡進行處理來簡化資料流程的處理呢？
用流程資料來代替標記資料。
如：chufang_mx表中，bz為標記該處方的狀態：1－劃價，2－收費，3－取藥，4－退藥，5－退費審核，6－退費。
用流程資料表示：建立乙個用於維護處方資料流程的表chufang_lc(chufangid, hj,sf,qy,ty,tfsh,tf)，每完成對該處方的處理，就將對應的流程資料置為1。作為流程，只要判斷當前流程是否處理及上一流程是否處理，就可以知道是否可以處理當前流程。這樣就可以輕鬆維護資料流程了（我現在實在厭煩在資料庫的設計文件上標記各種狀態值的含義，還有就是判斷當前的處理是否滿足流程要求，有沒有跨過流程處理的可能性。）
對於以上設計，按照資料庫的設計原則，可以設計為兩個表：流程記錄表（流程記錄id，流程描述），流程記錄明細表（流程記錄id，流程記錄序號，流程步驟描述，流程執行標記（布林值）），這兩個表中的資料和業務資料對應。
再加上兩個流程維護表：流程資訊表（流程id，流程描述），流程資訊明細表（流程id，流程序號，流程步驟描述）
對於流程維護表，其資訊也可以將其繫結於處理這些資料物件上，因為同乙個資料集，其處理物件不同，就意味著其處理流程不同，並且可以為處理物件的各個方法標上流程中的處理序號，這樣就可以輕鬆判斷處理物件上的某個方法當前是否可以處理他對應的資料了。
對於流程，為什麼不直接在設計某個實體的時候，直接給他加上流程編碼呢？比如給處方表加上lc，那麼定義：lc=1時，處方劃價；lc=2時，處方收費。這樣也可以體現流程資訊。
經過幾天這幾天的思考,發現同乙個資料,在系統流程的不同環節,對其的描述不一樣.這就有一點像在現實生活中，對同乙個人，處於不同環境的其它人對它的描述肯定不一樣。而對於這個描述，其特徵應該是復合的，即對於這個人的描述是綜合了這個人的乙個或者多個特徵的組合來完成的。比如說：老師說小明是乙個好學生，那麼老師說這句話的時候，老師的大腦裡一定出現了小明平時的幾個特徵：上課專心聽講，積極發言，認真完成作業等等。而小明的媽媽說小明是乙個乖兒子，媽媽在說這句話的時候，大腦裡出現的是小明的其它特徵：有孝心，成績好，能夠體諒媽媽等等。這就說明，乙個物件在對另乙個物件進行處理時，是綜合了它的特徵的。那麼就是說，物件應該有乙個它的特徵列表，這個特徵列表是這個物件在處理中的前提。
呵呵，這個好像有點像遊戲設計了。其實在處理商業邏輯中，也應該是這個道理。把那些分散的標記管理起來，然後對商業的邏輯物件進行處理。
根據以上思路，必須在系統中註冊各個物件的描述，這些描述是系統資料處理的依據，它對了物件的特徵集，而物件的每乙個特徵都有相應的處理方法。
關於資料庫設計的思考（一）
最近大半年由於公司上馬遊戲專案，自己轉向前台開發，專注於 flex flash js 開發，很久沒有進行後台的開發了。但最後這個遊戲專案不了了之，這兩個月又重新轉回開發網頁程式。在這之前，自己進行後台開發都是一些比較小的專案，設計資料庫都是很隨意的，兩三個人溝通好就行了，溝通起來也很方便。今次公司重...
資料庫設計之外鍵的思考
關於是否使用外來鍵在業界也沒有統一的標準，大家爭論的焦點是資料一致性和效能上。支援使用外來鍵方，強調如果不使用外來鍵，資料一致性無法保證，效能消耗可以忽略。反對使用外來鍵方，資料一致性可以通過程式保證，效能有大問題，資料維護很麻煩，如果是大系統，整個外來鍵的關係就像編制的一張大網。再者開發人員很難真...
MySQL資料庫 關於查詢 隨筆
select id,title,haha mark from course select from select from relation temp left join audio audio on audio.id temp.audio id order by temp.id desc批量更新條...