甲骨文公司副總裁及大中華區技術產品事業部總經理吳承楊強調：整合信息系統是企業像大數據時代過渡的一項重要舉措，構建數據庫要從平台層考慮，而非應用層，從而避免信息孤島的形成。在開發關系型數據庫時，應首推甲骨文的企業級數據庫。
今天的CIO在選擇數據庫平台時都應從哪些角度來進行考量？
我覺得首先來看一看今天企業裡面經常談的一個問題就是整合的問題。為什麼會談到整合的問題，因為整合就是你現在有很多沒有被整合的東西，所以是信息孤島，因為有信息孤島的存在，所以需要整合。反過來講為什麼信息孤島會存在，誰都沒有希望在建系統的時候要把它做成一個孤島。原因在於很多時候CIO在選擇建一個整個企業的系統的時候，它是希望由應用來驅動。也就是說他在不斷建一個一個應用，比如說我要建一個ERP的應用，比如說我需要建一個人事的應用，等等有各種各樣的應用，有風險的應用。這樣你會發現每一個應用他都建立起來了，但是當他建立了十個、二十個，比如說一個銀行最少有七八十個應用，建了七八十個應用以後，他就發現原來應用和應用系統之間就開始有信息孤島，然後他開始希望做整合。實際上如果說你選擇的時候如果多考慮一下平台層的問題，你可以讓信息孤島的問題有很大程度在早期就能解決，而不是到事後解決。這個平台層，實際上最重要的一點首先就是應該考慮數據庫。你數據的庫的選擇是非常非常重要的一點，所以說如果說我覺得我給CIO第一個建議，你首先要考慮建一個平台，而不僅僅是說根據你的業務需要建各種各樣的應用，應用是需要的，但是平台也是非常重要的。這樣在數據庫的選擇上，我覺得重要的一點在於你應該用一個數據庫即雲的服務這樣一個概念來選擇。
大家可能會問，你今天來講怎麼樣建數據庫的雲服務呢？大家知道現在有很多種數據庫，甲骨文當然是其中最重要的一種關系型的數據庫。甲骨文的市場份額也非常高，超過了50%。但是你會發現還有一些其他的數據庫，甚至於還有一些開源的數據庫。比如說甲骨文非常著名的MySQL當然還有一些其他的比如說非關系型的數據庫，比如noSQL，這些東西怎麼選擇呢？你既然要建立一個database service的平台，你首先應該想清楚哪些你是關系型的，哪些是非關系型的，這個是最重要的一點。你今天來講，你不可能用一個關系型的數據庫來解決所有的非關系型和關系型的問題。這個世界不是一個只是非黑即白的世界，簡單來講，比如說大家知道非關系型裡面很重要一點就是noSQL和Hadoop，這裡面是最著名的技術，現在業界有一種思潮認為我可以用Hadoop解決所有的問題，不僅僅可以解決非關系型的問題，也可以解決關系型的問題。這個選擇這個想法對不對呢？這個答案首先我可以告訴各位肯定是錯誤的，為什麼這麼講？因為Hadoop實際上是谷歌發明的技術，但是今天即使在谷歌本身它關系型的數據庫也是由關系型的數據庫解決的，並不是用Hadoop解決的。
第二個問題在於，我是不是可以用MySQL來解決這個問題呢？大家說既然我同意了我不用Hadoop來解決這個問題。我用MySQL來解決這個問題可以嗎，MySQL也是一個關系型數據庫，只是它開源而已。這裡面首先應該有一個很明確的一點，不管是甲骨文所有的企業級數據庫和甲骨文的MySQL數據庫都是來自於同一家公司甲骨文。MySQL我們的定位它是解決一些簡單的事物性工作，而企業級是用甲骨文的企業級數據庫，大家說我是不是可以企業級的也是可以用MySQL解決，你到底希望你的投資是在數據庫層面上還是在整個應用層面上。因為MySQL這樣的原因它沒有辦法支撐數據量很大的情況，所以他就要求把數據庫拆分。
舉個簡單的例子，假如說你是一個廚師，你希望你的後面有各種各樣的原料，你的原料裡面有肉，有魚，有蔬菜，可能還有一些其他的配料。你到底是用一個大冰箱來裝，還是分成若干個小冰箱來裝。如果說你分成若干個小冰箱裝，你就要明確肉是裝在1號冰箱的，魚是裝在2號冰箱的，你的蔬菜是3號冰箱。如果你還有各種各樣的配料，你一定要非常非常清楚。因此在應用層面，你就要確定我要取肉一定是從1號冰箱，但是如果說甲骨文的關系型數據庫，企業級數據庫你就是放在一個大冰箱，整個就是一個一千立升的冰箱，所有的東西擱進去，只要在這個冰箱裡面，就可以取到你想要的東西。這個實際上就是甲骨文的關系型數據庫，這是一個簡單的例子和MySQL的區別。
也就說你選擇甲骨文的企業級數據庫，對你來講，你在應用層相對來講，你是不需要做太多的工作。反而如果說你選擇了MySQL，你需要在應用層做很多的一些工作，確保你的分庫可以滿足你整個系統的要求。這點來講你要做一個選擇，不是說MySQL不能用，而在於你到底是需求什麼。大家會說對CIO來講，我就是希望在應用層做一些工作，然後我就把它拆成每個庫，是不是可以呢？答案是可以的。但是有一個問題大家不要忘記，第一你的這個集成商你需要以後一直靠著它，這樣你對集成商的需求性是很大的，依賴性很大。某種程度他是被集成商某種程度是綁定的，這是第一個問題。
第二個問題，因為未來數據庫很重要的一點不僅僅是這個數據庫本身，很重要一點是它的很多選件。如果說大家是使用照相機會知道，照相機上面會配各種各樣的鏡頭。照相機能拍出好多照片跟鏡頭是非常非常大的關系，MySQL上面相對的選件就會比較少，而甲骨文上面選件就會非常非常多，並不是這些功能不需要。比如說安全性，比如說數據的一致性等等這些方面，都是有各種各樣的一些選件。因此來講，當然你使用MySQL以後，這些選件你都需要找人來專門開發，這樣你才能達到性能。所以你可以看到如果你選擇MySQL，答案理論上是可以的，問題是你是不是願意投入這麼多的資源來做這樣一件事情，我們實際上大家可以看到現在業界流行的方法，你把這些專業的事情留給專業的人做，其實作為一個企業來講，數據庫的開發，選件的開發並不是你的強項，你的強項是業務。
因此你應該把數據庫的事情給專業的數據庫的人來做，這就是甲骨文來做。所以總體來講我們給CIO的建議，第一在你選擇你的應用的時候，在你選擇整個系統的時候，不應該僅僅考慮應用層，一定要選擇平台層，以減少你未來的信息孤島的風險。再選擇平台層的時候，最重要的是數據庫，數據庫的選擇，今天用Hadoop來解決所有的問題是不可能的，反過來講，用MySQL一種開源的數據庫，和甲骨文來比，的的確確都可以解決關系型數據庫的問題。但是問題是大家的價值取向不一樣，如果按照總體擁有成本來說一定是甲骨文的企業級數據庫擁有更好的TCO。
