我接触的许多企业都是从一个部门的数据集市开始进行预先规划、使用统一的规模，然后再建立额外的部门数据集市。他们认为数据库未来的需求会不断增长，数据集市会变成一个企业仓库，于是把数据库的基础架构设计得异常庞大，毫不考虑短期需求。

　　在这个演变过程中，两个方面有可能破坏这个简单方法。一是，其他部门启动了相似的项目。他们建立了自己的数据仓库，两个、三个、四个系统开始在企业中同时增长。二是，企业无法精确评估系统增长的速度。他们由于意识到日后改造系统的不易，因此高估了系统的增长速度，一开始就去实施一个巨型基础架构。

　　最后，必须将这些系统合并成为一个真实版本。撇开政治因素与选址问题不谈，他们所合并的平台必须能够处理这些负载。许多企业被束缚到了某一个平台上，即便该平台已不再具备处理负载问题的能力，也无法进行转移。重新设计数据仓库平台是一个很大的负担，应该尽量避免。因此，预先理解平台的扩展能力，有利于确定数据仓库合并或首次创建时应该选择的平台。

　　注：根据我的经验，数据仓库的增长速度比预想的快得多。如果今天数据仓库的大小为1TB，我们很难确定三年后是不是会增长为15TB。一旦达到15TB，用户就会开始抱怨性能问题了。

　　多个数据仓库在授权、人员支持及维护方面的开销可能非常高昂。另外需要注意，这些数据仓库通常在相互竞争的平台上运行，所以想要享受从一个供应商处购买多个软件授权和相似硬件的折扣是不可能的。既然使用不同的平台，那么IT人员必须掌握大量不同的技术，从而导致人员成本的提高。此外，托管数据集市的经济型数据库系统通常无法扩展到企业级数据仓库的规模。

　　我在这里并不反对将数据集市扩展成为企业数据仓库。这是一种非常有效的技术，具有很多优点，随其增长也能给用户带来很好的回报。问题在于我们必须仔细选择用于创建数据集市的平台。这个平台是否支持多个数据集市?它是否可以根据需求进行持续扩展?

　　这些问题随即带来一些特殊需求。数据仓库平台必须能够扩展，以符合快速增长需求。在项目启动时具备高性能、在工作负载持续发展扩大时仍能保持其性能水平的系统才是首选系统。