先說明一下系統二次上線：今年3月份上線了辦公和財務，這次上線生產管理系統，用的是同乙個資料庫，同時也屬於同乙個專案的不同階段，故而誠摯慰問二次上線。
目前在某電網的子公司做乙個管理系統，採用多個子模組迭代開發的方式，因此用的是同乙個資料庫，子模組多次開發最頭疼的應該就是資料庫的更新了。上線的是辦公和財務子系統，
9月份上線生產管理系統，本文章主要談談資料庫維護的一些體會。
資料庫設計我們用
powerdesinger(
下文簡稱
pd)，
pd可以生成
sql語句，執行
sql語句後就可以生成表結構。因為年初發布的時候我們只執行了辦公和財務的
sql語句，所以現在我們只能在現有資料庫上執行生產管理的
sql語句（在
pd中生成）。所以目前問題的關鍵就是如何保證
pd的資料庫設計是最新的。
當然，這個時候就有人問，問什麼
pd不能保證是最新的呢？其實，有過開發經驗的人都會知道資料庫設計在開發過程中是會不斷微調的。這也不全歸咎於設計人員的水平，因為客戶業務是會變得，因此資料庫出現微調是必然的。
因此，我們只能擁抱變化，呵呵，如何擁抱呢？採取如下方法：
1、修改資料庫，發郵件通知
pd維護人員
2、pd
人員，以週為單位更新資料庫。
從理論上來講這樣維護出來的
pd肯定是最新的，但是理論終歸是理論太多於理想化，開發過程中肯定有開發人員修改了資料庫沒有傳送郵件，
pd維護人員沒有更新的情況存在。那怎麼辦呢？
只能採取「軟著路」的方法了。我們在系統上線一周前，我們備份生產機的資料庫下來，將最新的
pd生成的
sql語句執行上去，並且進行
bvt測試（把所有的業務流程從頭到尾走一邊）。其實這個過程還是很痛苦的，因為有的資料表缺少字段，有的應該是非必填欄位弄成了必填字段。。。經過了一天多的測試，終於把所有所有資料庫問題都解決了，在這個過程中，我們記錄下每一條執行的
sql語句
(便於發布到正式的資料庫
)，在把它發給
pd維護人員。
可能有人會問，為什麼都不能直接把剛才那個資料庫直接還原呢？呵呵，因為我們之前上線的系統在工作日幾乎每個小時都會有資料產生，所以只能在週末把正式資料庫還原上去，然後在執行
pd中的
sql並執行修改後的
sql，並將其還原的生產環境。最終，我們利用週末兩天的時間成功上線了。
回想整個過程，如果我們當初沒有維護
pd的話，由於資料庫的差異造成的阻力肯定是很大的。經過了這個我們也意識到了更新
pd的性了。
系統分析與設計第二次作業
1 簡答題 1 簡述瀑布模型 增量模型 螺旋模型 含原型方法 的優缺點 瀑布模型 瀑布模型是最基本的一種可供選擇的軟體開發生命週期模型。優點 降低軟體開發的複雜程度，提高軟體開發過程的透明性，提高軟體開發過程的可管理性 推遲軟體實現，強調在軟體實現前必須進行分析和設計工作 以專案的階段評審和文件控制...
系統分析與設計第二次作業
瀑布模型 缺點 增量模型 缺點 螺旋模型 含原型方法 缺點 三大特點 用例驅動 以架構為核心 迭代及增量。用例和風險驅動 迭代及增量體現了使用者驅動的開發。以架構為核心體現了風險驅動的開發。第一階段 先啟階段 inception 該階段的主要目的是建立專案的範圍和版本,確定專案目標的可行性和穩定性,...
系統分析與設計第二次作業
統一建模語言 uml 是描述 構造和文件化系統製品的視覺化語言。從其定義可知，uml的核心作用是 視覺化。該特點可以使得uml可以幫助專案參與者更直觀 清晰地認識其描述的物件。行為圖 實現圖 從軟體本質的角度，解釋軟體範圍 需求 控制的可行性 軟體的本質特徵為 複雜性 一致性 可變性 不可視性，這些...