近日在處理若干故障的時候，突然感覺到一種來自甲方的悲哀。
為什麼這麼說呢？
按說甲方是金主，很多事情都需要根據甲方的意思來辦，可是在資料庫選型上卻偏偏出了問題，而且還埋下了大坑。
為什麼什麼說呢？
我也參與過若干應用系統的售前、實施和驗收工作。在售前階段，甲方往往只關注業務系統功能上的實現，而忽略了最基礎的資料庫選型。在此過程中，業務系統開發廠家其實是在做潛移默化的引導，此處悲哀有如下幾點：
1、開發廠家只推薦自己熟悉使用的資料庫，而不去考慮長久的打算；
2、就算是開發廠家熟悉的資料庫，到了專案後期或交付之後，開發廠家一樣會把該資料庫甩出去，讓甲方去處理維保的事情。這是乙個很悲哀的事情，甲方明明前期未深入了解和控制資料庫這塊，到了後來卻需要找第三方或資料庫原廠來購買服務；
3、潛移默化的引導帶來的問題是資料庫許可的少量購買或不購買，換言之，所有的專案預算都會留給開發廠家。甲方預算了那麼多錢，通過這樣的乙個潛移默化過程，最好錢卻全部落入應用開發廠家的口袋裡。
出現上述問題的根本原因，我理解還是甲方對資料庫的不理解或理解的不深所致，也有鐵路警察各管一段的可能性。
其實關於資料庫選型，我的建議如下：
資料庫的選型和自己家裡買車我覺得是非常相像的，需要看你手裡有多少銀子；也需要看你對資料庫 需求是什麼（這點其實很多很多很多人是說不清楚的，也是不專業的，然後就被各種誤導）。
最明顯的例子是你明明是在市區代步，家裡日子還緊巴巴的，你非要去買個賓士大g回來，想想就覺得不現實，也是很搞笑的。
能說清楚應用對資料庫的需求，也了解自己兜裡有多少銀子，資料庫選型的事情就基本上一目了然了。
在資料庫應用系統中資料庫的開發
在資料庫應用系統中資料庫的開發 乙個成功的資訊管理系統由50 的業務 50 的軟體組成 而50 的軟體又是由25 的程式 25 的資料庫組成。由此可見資料庫在資訊管理系統中佔的重要位置，或許會有人說了 資料庫不就是建幾張表嗎？有那麼重要嗎？如果按照你說的那樣，既然ms已經有了vb 大家都知道vb中自...
怎麼進行業務系統資料庫技術選型？
隨著雲計算 大資料 物聯網時代的到來，越來越多的網民湧入網際網路，越來越多的應用系統需要支撐海量資料儲存，還需要隨著業務需求滿足高併發 高可靠 高擴充套件性等要求，傳統的關係型資料庫已經不能完全滿足需求了，因此nosql應運而生。那麼sql是什麼?nosql又是什麼?業務系統如何資料庫技術選型呢?n...
UML與資料庫應用系統
uml 定義由語義和表示法兩部分組成，語義用自然語言描述，表示法定義了uml的視覺化標準表示符號，這決定了uml是一種視覺化的建模語言。uml的語義是定義在乙個四層 四個抽象級 建模概念框架中的，分別是 元元模型層 組成uml的最基本元素 事物 元模型層 組成uml的基本元素，每個概念是元元模型中 ...