把营业体系和产物体系离开，删除数据库体系中的产物智能。斟酌公司的内部需求以及在产物内或产物间传翰数据的情形。从数据库中删除存储进程，把它们放在运用逻辑中。不要在企业体系和产物体系之间进行同步骤用。把运用逻辑放在数据库中成本很高且难以扩大。把企业体系和产物体系绑定在一路，成本也很高，不仅难以扩大，可用性也令人担心。

因为允许和单一体系的特征，数据库和内部企业体系的扩大成本会很高。是以，我们愿望它们能专注于履行特定的义务。就数据库而言，我们愿望它们可以或许专注于事务而不是产物智能。就后台办公体系(贸易智能)而言，我们不愿望产物与体系的扩大才能接洽在一路。对于营业体系的数据，采取异步传输模式。

我们经常告知客户，要避免在关系数据库中应用存储进程。他们的第一反响平日是:“你们为什么这么憎恶存储进程呢?”其实我们并不憎恶存储进程，我们在许多情形下也在用它们。但问题在于，存储进程经常在解决计划中被过度应用，而这种过度应用有时会造成体系中的扩大瓶。既然这个原则强调的是数据库方面的问题，那为什么不把这个原则放在数据库那章中呢?事实上我们存眷存储进程的真正原因是，我们主意把贸易智能和产物智能与事务处置区离开来。一般说来，这个主意可以进一步归纳综合为“把类似的事务放在一路(或者说把分歧的事务离开)以获取最年夜的可用性和可扩大性以及最低的成本”。如许的表述可能不太好懂得，是以让我们仍以存储进程和数据库为例，解释为什么须要这种区分。

在你的架构中、数据库可能是最贵的体系或办事之一。即使采取的是开源数据库，这些体系地点的办事器也可能会衔接到成原形对较高的存储解决计划(相对于你其他的解决计划而言)，它们具有最快、最年夜数目的处置器以及最年夜数目的内存。在成熟的情况中中，这些体系平日都被用于做一件工作、即履行关系操作，并把事务尽可能快地提交给稳固的存储引。这些体系上的每个盘算周期的成本都比架构中的其他解决计划或办事(如运用办事器或web办事器)要高。这些体系是某些办事的汇集点、也是泳道的界说点。在极端情形下，如在架构的初期，这些体系所占的比例可能更为伟大的，那么它们显然是影响全部情况的扩大的决议性身分。

出于以上这些原因，把这种昂贵的盘算资本用于营业逻辑几乎是毫无意义的。这时每个事务所花的成本会增长，因为处置这些事务的体系的操作成本更为昂贵了。同日时这个体系自己也可能是影响我们扩大的决议性身分，那么为什么我们还要糟蹋临盆力在它上面运行与事务处置不相干的操作呢?是以，我们应当让这些体系只处置与数据库(或相干的存储或NOSQL)相干的事务，以便让它们做本身最善于的工作。如许我们不仅进步了可扩大性，还能削减扩大成本。

在数据库这个例子中，我们把不类似的服各区离开可以运用到架构中的其他环节。我们很可能会有后台办公体系，诸如发送和吸收电子邮件(与平台无关)的体系、做总账和其他管帐事务的体系、市场细分的体系，以及支撑客户户的运维体系，等等。我们很可能会把这些体系一股脑地放到我们的平台上。我们可能愿望电子商务体系中的一笔生意业务能连忙显示在我们CFO的ERP体系中，或者我们想让客户支撑代表能连忙看到它，以免这笔生意业务出问题。同样地，假如我们运行的是一个告白平台，那么我们可能想及时剖析数据仓库中的数据，以便给出更好的告白建议。有许多原因促使我们想把营业流程与产物平台中的体系混在一路。然则，我们的建议很简略:不要如许做。

幻想的情形是，让这些体系都能依据本身的须要自力地进行扩大。假如把这些体系绑定在一路，那么当一个体系须要扩大时，所有体系都要同时扩大。在某些情形下，如用数据库履行营业逻辑，体系的扩大成本会更高。允许证是与CPU相干联的ERP体系就经常会产生这种情形。假如每个事务都同步骤用ERP体系，那么扩大成本必定会进步。此外，把体系以串联方法参加平台，也会下降产物的可用性，那么为什么我们还要如斯做呢?

就像不该该把产物智能放在数据库中一样，贸易智能也不该该绑定到产物事务上。在很多情形下，我们须要让数据驻留在我们的产物中并且此时我们最好让数据驻留在产物中。我们可以从其他体系中选择数据集，在产物中准确地表现出来。平日，最好用一种新的或分歧的方法表现这些数据，有时是采取分歧的范式。我们经常须要把数据从产物移到后台的营业体系中，如客户支撑体系、市场营销体系、数据仓库和ERP体系。在这些情形下，我们也愿望可以或许用分歧的方法总结或表现数据。此外，为了进步可用性，我们愿望以异步方法在体系间传输这些数据。为此可以采取ETL(提取、转换、加载)体系，甚至还有许多开源对象可以赞助你构建本身的ETL进程。

记住，网站制造模式并不料味着是“旧”数据。没有来由选择过时的数据元素在体系间进行传输。此外，还可以把数据宣布到某种新闻总线上，以供其他体系应用。成本最低的解决计划是批提取，不外假如时光有限不许可采取这种办法，那么新闻总线绝对是个好选择。