一直以来，在企业选择数据库引擎时，几乎完全是由其应用来驱动的。当一家公司需要库存管理系统或HR系统时，购买决策通常是基于应用程序的兼容性，而负责决策的人并不在乎软件是基于哪类交易型数据库的。这样做的结果，通常会导致数据库数量激增，如果发生收购或合并，数据库数量增长的速度则更快。

　　过去，应用程序通常作为各部门内部的独立系统，无需向组织其他部门输出任何东西或从其他部门输入任何东西。如果应用孤立的状况一直持续下去，那么现在对数据库标准化的需求将更少。然而，情况已有所改变。

　　部门级系统的设计初衷是用来运行交易。现在我们看到的对信息的迫切需求，已不仅是原始的交易型数据。企业可以使用商业智能（BI）和分析的发现来获得竞争优势，而这需要关联来自多个交易处理系统的数据。如果所有这些需要抽取数据的系统运行在同一个数据库引擎上，则会使数据的集成和关联工作更容易。

　　为BI系统抽取所需数据是数据库标准化的主要业务驱动力。它也存在一些潜在优势，最重要的是在这充满经济挑战的时代，降低数据库的维护和集成成本。数据库管理团队可以专注于保留的数据库引擎，甚至还可以缩减团队的规模（请在解雇团队成员之前读完本篇文章）。

　　软件许可费用也可以减少。如果你的企业有六个应用程序运行在不同的数据库平台上，你必须为六个不同的数据库支付许可费用。如果你将其统一在一个单一的平台上，虽然数据库成本不会消失，但你可以通过批量许可方式获得更大的折扣。

　　早期的数据库市场中，有许多可用的事务型数据库引擎，然而用户往往被他们开发的应用程序所局限，只能运行在特定的数据库上，这时提出数据库标准化是不可能的。现如今，主流关系型数据库的数量已减少到几种，并且大多数主流应用程序都能在其中任一个上运行。因此，在大多数情况下，应用程序的兼容度不再是标准化数据库的考量范围。事实上，现在的考量角度正好相反，如果不能支持广泛的数据库平台，那这个应用就可以pass掉；一个应用程序无法运行在主流数据库平台上，那么它的“生命力”就值得怀疑。

　　数据库标准化：量力而行

　　但是，任何标准化政策都应该基于企业的业务需求，不应该围绕业务运营和BI过程采取一刀切的办法。到目前为止，本文的重点一直是交易型数据库引擎。选择一个主流关系型数据库管理系统用于运行交易处理应用程序将很有意义。

　　但强迫分析型系统使用RDBMS对于许多组织是没有任何意义的。此外，许多企业使用轻量级数据库如Microsoft Access来开发应用或支持几个最终用户 。例如，管理一份小制造商采购部门中只有六个人使用的电话清单，此类应用程序并不适合成熟的关系型数据库。

　　总体而言，最好是保持开放的态度，不要试图迫使整个公司采用单一的数据库平台。例如，你可能考虑将你主要的交易处理系统、一个多维产品或其它专门用于BI和数据仓库的分析数据库标准化成一个关系型数据库引擎，以及为小规模应用选择一个桌面数据库引擎。

　　当然，不同的技术都需要数据库团队的支持和维护。但如果你成功地减少了数据库平台，也就是说，将六个事务型数据库、两个分析型数据库以及三个桌面数据库规范成三个，那么效率得到提高，成本得以降低，这几乎是必然的。