企业应用设计讲究折中，而其中很大一部分涉及性能、负担能力和可靠性。虽然这个领域中SAP有很多可以讲，但是本文主要关注于SAP数据库整合战略的最新变化，对于SAP客户和合作伙伴在应用设计上要提起注意。

SAP一直都在尽力将应用逻辑从数据库分离，避免使用数据库持有的特性，并且推荐客户和合作伙伴也这样做。SAP在很多地方采用这种方法，但是它特别在整合SAP Business Suite的最佳应用指南中指出：“开发者的应用应该尝试将他们的软件从底层数据库分离，以便实现最大的灵活性。”

SAP传统上更看重灵活性而不是性能

这个策略在不同的应用类型上会有不同的体现。

图1：SAP的传统设计策略要求只使用SQL在数据库上执行业务逻辑。当大多数逻辑发生在应用服务器或数据库的SQL执行上，那么这种方式都是可行的，但可能会有一些难度，特别是在混合应用程序中。

在一些传统应用程序上，如SAP Business Suite组件，它会增加应用服务器的计算负载。同时，对于SAP和BusinessObjects BI领域的分析应用程序，这个策略会通过纯SQL向数据库服务推送尽可能多的计算负载。当计算无法通过SQL完成时，业务逻辑将转移到应用服务器上实现。但是，由于高性能和混合应用程序需要在一个应用程序上同时执行交易逻辑和分析逻辑，所以它们会暴露这种设计策略的一些问题。

在其他供应商的企业应用平台上，经常会有大量使用存储过程、触发器和将应用与某一种数据库紧密耦合的情况。SAP的方法更加灵活一些，但是它的缺点是需要重建一些重要数据功能，如应用服务器级别上的交易和查询优化器，以及数据库和应用程序之间有时增加的回路和更高容量的数据传输。

处理应用设计折中问题的策略

在很多时候，这些策略代表了性能与应用组件松耦合之间的折中方法。松耦合（或者说重用组件）是负担能力（重用组件比全新开发更便宜）和可靠性的主要动因，因为经过验证的组件可能更加可靠。

通过在数据库之间重用组件，SAP应用程序一直以牺牲数据库性能为代价提供负担能力和可靠性。一些SAP应用及由客户和合作伙伴开发的许多非NetWeaver应用都有不同的折中策略，它们通过深度整合数据库平台而利用这些数据库的性能优势。

HANA与SAP新策略

HANA的承诺之一是改变指导这些应用架构策略的折中方式。SAP坚持认为，HANA并不只是一个数据库，而是一个平台，这表明了SAP的应用设计新方法。值得注意的是，SAP Guidelines 现在加入了HANA平台的例外情况，它指出：“如果将SAP HANA作为持久层，那么持久层应该与应用逻辑分离。”

HANA加入了大多数传统数据库组件，数据管理与查询引擎、存储过程和工作负载管理等，但是它还包含大多数典型应用服务器的组件，如HANA内置的XS引擎和JavaScript Web与应用服务器。

这种新设计方向的一部分原因是它发现数据库与应用服务器之间存在一些延迟和带宽瓶颈，因此开发者并不需要自己决定应该将应用逻辑部署在什么位置。相反，您只需要将所有普通 数据库和应用服务器功能交给HANA处理。我们可以将它看作是一种新的二层架构 。

在HANA上实现的应用逻辑使用HANA自身的API，因此它的重用性会受到一定的影响。（它可以应用到HANA的任意平台上。）但是，它的优点是SAP仍然有空间去优化HANA系统中不同组件之间的交互。例如，XS引擎已经将逻辑下放到预编译的存储过程中，因此可以大大提升它们的性能，而且将来还可能更深入地整合到HANA的数据管理引擎上。

对于像混合事务或分析应用等有高数据处理和延迟要求的应用程序，将数据库和应用逻辑组合在一个系统上可以简化开发过程。对于没有这些需求的应用程序，它们也可以将HANA作为一个传统数据库，它提供标准的SQL API，也会提供企业所需要的灵活性。在开发应用程序时，一定要注意的问题是：怎么才能最好地平衡性能与灵活性。HANA提供了其他一些选项，但是原来的权衡方法仍然有效。