甲骨文公司副总裁及大中华区技术产品事业部总经理吴承杨强调：整合信息系统是企业像大数据时代过渡的一项重要举措，构建数据库要从平台层考虑，而非应用层，从而避免信息孤岛的形成。在开发关系型数据库时，应首推甲骨文的企业级数据库。

今天的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。