SAP并不符合"超越分布式事务的方法"一文中提出的解决方案，但作为一个大型系统已经考虑了伸缩性，并且与"超越分布式事务的方法"中的思想有些类似
1. 任何情况下不使用JOIN
实体可能被分区在任何一个数据库中，在实体之间如何跨越数据库的JOIN? No way!
单这一点足以难倒绝大部分的设计、架构师
a). 事务型的操作(OLTP)使用对象模型解决，分析、报表查询类的操作(OLAP)使用另外的解决方案，例如BI系统，或者特定的报表模块。SAP中也存在大量的分析报表，有系统标准提供的，有用户开发的，对这一部分不必遵守伸缩性原则，重新分区时分析模型、配置需要重新设置
b). 业务设计观念的转变(或者说正确的认识什么是业务设计，这一点应当是普遍的误解，或弱化、忽视了)
只有达到了这一点才可以考虑无限伸缩解决方案，达到了这点其他很多问题的解决也会变得简单很多
2. 实体粒度
SAP每个Client可以使用单独的数据库实例，但一个数据库实例中是否允许存在多个Client倒不太清楚了
一般Client在业务概念上映射到子集团，明显这个粒度太大了，可能这个原因在不少情况下是制约SAP性能的一个关键因素，导致为了解决性能问题硬件和实施成本过高
实体粒度太细也没有必要，对那些永远也不可能需要分布式的数据设计为实体，同样是浪费
实体的离散性、业务逻辑的复杂性、性能，这些因素之间总是相互影响和制约，如何在他们之间平衡取舍?
3. 实体键值
SAP使用Client Code作为实体键值，Client Code是一个独立的字段，同一个Client中实体对象(entity object，相对于value object而言)基本都有Client Code这个字段
SAP只是集团内部系统，Client映射到子集团，Client的概念类似魔兽中的不同区域服务器，不过SAP的Client之间数据可以传输、共享
用户在登陆系统时必须提供Client Code、账号和密码，所以这个Client Code就会贯穿用户登陆系统之后的所有操作。考虑amazon这种系统，这样的解决方案就不可行了，用户在登陆系统时还得选择一区域?
事务序列化范围肯定只局限于Client范围之内，Client之间将使用消息通讯完成数据传输
4. 消息
SAP的消息格式是IDoc，从文档结构上看具备自描述性
对消息与事务的管理、是否有消息重试、重订阅等幂等性处理机制不了解
IDoc除了用于Client之间的通讯，也用于外部系统与SAP之间的通讯