谨慎做数据库技术的标准化_Oracle教程

　　一些专栏文章之中，我提到过几年前我曾经工作过的财富100强中的大型公司。那里确实是一个工作的好地方，天天的工作都布满了挑战，假如你不喜欢你所做的事情，通常等上几个星期就会有新的事物出现。大型公司所面临的一个挑战就是各种不同的技术的增多。在我们的公司中，我们一直有一个标准化的开发体系结构，问题是每三到五年，这个体系结构就会发生变化。从数据库的角度来讲，我们有面向flat-file(由不包括重复组的一组同类型记录构成的文件)的应用软件（我知道不是数据库），VSAM（我知道它不是真正的数据库），IMS，Adabas，Datacom，DB2，Oracle，Sybase，而且我相信还有一些其他的。当SQL Server出现时，我们立即就将剩下的一些应用软件转移出了Adabas。
　　
　　
　　
　　很显然，员工们不会在1975年时坐下来计划公司在25之内使用10个文件的系统。关于标准化技术的决策制定在逐渐地增多，而且都有着很好的原因。IMS比VSAM要好得多，Datacom又比IMS好得多。DB2出现得比较晚并被视为未来的关系数据库。然而，对于客户机服务器来说，他们都不合适。因此，Oracle出现了。现在，谁还能忽视微软和SQL Server的存在呢？
　　
　　数据库过多的另一个原因就是公司的合并和收购。两个公司可能都具有非常简单的技术环境，然而，当他们合并时，就会开始出现混乱，再加上第三个公司，那就会出现麻烦了。公司的技术环境通常不是收购的原因，也不是一个障碍，它只是在收购之后需要协调的一些事情。
　　
　　不管怎样，最后你都会面对一片混乱，出现的问题涉及到两至三种数据库技术，有时候会有五至六种，甚至是十种！
　　
　　多种数据库技术带来效率的降低
　　在应用软件支持环境下工作或是对其进行治理的所有人都很熟悉，多种数据库技术所带来的麻烦。
　　
　　许可成本。维持多个数据库的成本是非常昂贵的。你的公司并没有得到许可优惠带来的好处。一般来讲你可能是一个大型数据库的用户，但对于很多独立的数据库来说你只是一个小型的用户。
　　升级成本。在多个数据库之中，似乎总是有一个或几个数据库需要进行升级。有时你刚刚对其中一个完成升级而另一个也需要升级了。除非在性能上有显著的提升，那么数据库的升级就是一个不可避免的麻烦，通常只能带来边缘商业价值。
　　培训。在具有很多种数据库的公司之中，似乎每个人都需要把握两种到三种。例如，假如你在客户机服务器领域或是Web开发领域工作，你就要懂得Oracle和SQL Server。这就是为什么有时你在招聘时的工作描述中看到要求具有两三种数据库方面的知识的原因了。很多与数据库相关的理念在数据库与数据库之间都是相通的，然而，他们又都有着各自独特的特点，让人很难成为数据库方面的专家。
　　DBA技能。在数据库领域，数据库治理员是真正的专家，对于他们来说，获得并维持多种数据库的专业级知识是非常困难的。事实上，假如不是为了支持所有的数据库技术所必需的广泛的技能的话，你所具有的DBA很可能比实际需要的更多。
　　解决方案
　　
　　
　　假如你能选择的话，你可能不会希望处在维护多种数据库技术的境地之中。然而，很多情况时，事情是不受你控制的。
　　
　　这个问题的最佳解决方案就是进行计划时你的眼光至少要放在未来的三年以上。你的眼光需要放长远，因为短期性的数据库转换所带来的辛劳和成本总会比短期性利益要多。然而，假如你的眼光放长远的话，长期性的收益和成本的节约就会变得更加有吸引力。这里是一些你可以采取的步骤：
　　
　　确定什么样的技术最应该进行标准化，而什么样的技术最应该停止使用。这个决策可以从成本，技术和功能特性的角度来制定。
　　着眼于非标准化数据库技术，看一看是否有进行转换的机会。例如，很多行销商推出的数据包支持多个数据库技术。在你下一次的升级工作时，也许你也可以从非标准化数据库向标准化数据库进行转换。
　　很多旧有的应用软件将会退役或被取代。在这个转换过程之中，你也可以进行数据库方面的转换。
　　查看商业计划中需要进行实质性改动或提升的地方。在对应用软件做出实质性改动的同时，也许就会有机会对非标准化数据库进行转换或使其退役。
　　监控非标准化数据库所使用范围。首先，新的应用软件不应该使用非标准化数据库进行开发。第二点，因为应用软件环境会不断地升级，你会发现非标准化数据库只被少数应用软件所使用，也许只有一个。而完全去除掉一个数据库所节省的许可成本就可以弥补事先移植这些应用软件所花费的成本。
　　大多数中型或大型的IT开发环境中都存在着数据库技术的混乱。你的公司需要了解并量化支持这种环境所需要付出的努力，这里包括许可成本和雇用具有恰当技能的人员。从严格的成本/收益的角度来讲，向公共技术平台进行移植所带来的商业价值很少能在短期之内体现出来。然而，假如你有一个长期的体系构想的话，你就会发现很多放弃旧有的数据库技术的机会。你的眼光不应该放在今天或是明天，而至少应该是在三年之后。