EAS使用UUID作主键已经很多年了，K3 HR也是。但遇到的问题应该都不少，今天在Martin Fowler的书中读到这么一句话：GUID唯一的缺点在于生成的串比较大，这可能会成为一个大问题。
后面还紧跟了一句：长键总是难于输入也难于读写，这也会带来性能问题，尤其是对索引。

呵呵，看来Martin大叔是也是深有体会的，其实我们后来遇到的很多问题都是与之相关的。
1）数据太大导致数据库过大。和K3同等数据量的账套相比，EAS的账套要大许多，这中间GUID的贡献就“功不可没”
2）索引问题：使用GUID之后关联属性都是大字符串，而这都是索引字段，于是乎索引性能问题出来了。
        假设数据库页大小为m，索引项大小为n，那么一个页上所能容纳的索引个数 t= [m/n]，可以认为磁盘的读写速度恒定（假设1秒读入p页），那么索引的访问速度是v=p*t=p*m/n，即访问速度与索引项大小成反比。（此处没考虑B树本身的查询时间，只是考虑叶子节点的访问时间）。
3）虚模式问题。由于GUID过大，JVM又有最大内存限制，因此使用GUID做PK的虚模式在高并发下极易造成OOM，后期被迫改为TempTable方案，可惜又遇到不同数据库物理临时表的问题。这就是为什么让人感觉EAS的虚模式很复杂的原因，其实本质和K3没什么区别，只是牺牲在GUID上而已。

        其实我们可以分析一下使用GUID的一个主要原因。我们的GUID本质就是一个IdentityField，即对应BOS中的主键（PK），对于PK有三点需要考虑：
    1）有意义还是无意义。
            比如凭证，如果我们选择凭证编号做PK，就是有意义PK，我们目前使用的应该是无意义PK，仅做内部标识。
    2）单一还是复合
            我们使用一个ID做PK，很明显是单一，慢着，真的是单一吗？一张表里可以有多种单据的数据啊？类型去哪里了呢？其实我们的ID现在应该是ID ＋ BOSType的复合，只是由于BOSType的唯一性，使得我们可以将两个信息融合到一个ID中。这样合理是否真的合适我不敢肯定。

    3）唯一性
            所谓的唯一性实际上是由一个作用域的，就像我们进行业务建模，也是有领域一说，这就是域模型的一个特征吧。唯一可以是当前库表唯一（或者叫做域唯一），当前系统唯一，全球唯一，很显然EAS是选择后者。
            
     在我心目中对于Identity 应该是这样的：
    1）Identity应该只是一种唯一性标志，一个对象可以有多个IdentityField，适用于不同场景。
    2）Identity应该是一个对象，这个对象可以只有一个属性，也可以有多个属性，即可以单一可以复合。
    3）频繁使用的Identity应该是域唯一的，这样可以做到短小精干。

    以EAS作例子，我认为Identity应该分为两种：
        InnerIdentity和OuterIdentity

    InnerIdentity应该包含：一个Int型的Identity列，一个BOSType列，一个Version列（String型）。
        InnerIdentity只在系统内部使用，比如关联属性就变为一个复合关联，ORMMapping也许就会变成：
            A.FinterID=B.FxxxInterID AND A.FVersion = B.FxxxVersion AND A.FBOSType =B.FxxxBosType
    OuterIdentity则包含：一个GUID列，一个BOSType列，一个Version（String型）。其中后两个信息是对InnerIdentity中相同属性的引用。

         OuterIdentity的主要用于外部数据交换。比如WEBService，异构数据导入导出等场合。

       新版本的EAS中，已经越来越接近了。