1、問題描述
近期在做乙個審批工作流的系統，在和客戶交流的過程中，總是聽到「你們的系統要支援我們的業務發展，***天我們要上***產品，你們的系統也要支援***產品的審批」；當然，不同產品的審批內容不同、流程不同。在這裡先說下怎麼解決業務資料結構的變更。
2、解決方法
想要不改程式就實現對業務資料結構變更的支援，基本上是不太可能的，我們只能做到盡量少修改一些**，目標是：不改變資料庫表結構和dao層。上網查了一些資料，總結如下：
a、最理想的情況
在需求階段窮盡客戶的需求，不產生業務變更，但這是不可能滴:)
b、預留字段
在資料庫設計的初期，增加預留字段。這個辦法比較簡單，但在實際應用中並不樂觀。面對的問題是：資料庫設計時，預留什麼型別的字段？預留多少字段？預留欄位與業務資料字段的對應關係如何維護？
c、縱表
縱表是相對於橫表的乙個概念。橫表就是普通的建表方式，如乙個表結構為：
主鍵、欄位1、欄位2、欄位3 ，如果變成縱表後，則表結構為： 主鍵、字段**、字段值。 而字段**則為字段1、欄位2、欄位3。
資料庫設計階段，將業務物件的相對固定的字段使用橫表儲存，可能發生變化的字段使用縱表儲存；實現dao層時，同時/分別操作橫表和縱表，實現業務物件的crup。
面臨的問題：當出現比較特殊的資料域時（比如：**、大檔案），還是需要對資料庫和dao進行修改。
*採用橫表+縱表，而不是只使用縱表，是考慮到單錶資料量的問題，還有就是資料的使用頻率問題。
d、不用關係型資料庫
也有人這樣建議。
如何適應業務流程的變更
1 問題描述 近期在做乙個審批工作流的系統，在和客戶交流的過程中，總是聽到 你們的系統要支援我們的業務發展，天我們要上 產品，你們的系統也要支援 產品的審批 當然，不同產品的審批內容不同 流程不同。針對業務流程變更，結合做過的兩個專案，說下個人的想法。2 專案介紹 a 外包管理平台 負責信用卡申請過...
如何降低平台和業務的資料結構的耦合
問題背景 系統的模組劃分為平台和業務，分別由平台組和業務組各自維護各自的 typedef struct plat container int a1 平台用 int a2 平台用 int p an 平台用 int serv11 業務1用 int serv12 業務1用 int servn 業務n 用 ...
旁述 測試過程中如何應對頻繁的版本變更？
旁述 測試過程中如何應對頻繁的版本變更？對於這個問題，其實要視實際的情況，如企業 團隊 專案 產品 市場等等多個方面的因素，不能一概而論，所以，解決的辦法有多種。今天我沒有回答 如何應對 頻繁的版本變更這個問題，下面的內容，當作提醒，呵呵。1 為什麼會有頻繁的變更？2 多少變更可以集成為乙個 版本 ...