SQL
　　SQL/SP/JDBC在这里属于一类，这是老牌的数据计算层，性能和灵活性是它的优势。但随着新情况的不断出现，单纯用SQL已经难以满足需求，比如： JAVA开发规模的扩大，数据量的剧增，复杂计算问题的涌现。虽然SQL得高分的指标不多，但都是权重高的。
　　成熟度：5星。成熟的。
　　低耦合性：0星。耦合性极高。除了在实验室之外，几乎不可能写出与数据库无关，与代码无关的计算脚本。
　　脚本编写：3星。SQL实际很难写出也很难维护，需要大量的时间去学习，好在SQL非常成熟，资料丰富论坛很多。但各种数据之间的不兼容也是个巨大的障碍，这是Hibernate之所以流行的主因。
　　集成：5星。JAVA程序员的第一课是用JDBC连接数据库。
　　界面友好性：5星。有大量的SQL开发工具，成熟度都很高，我自己用过不下10种。
　　性能：5星。数据库直接支持的语言，性能高。
　　复杂计算：3星。SQL适合普通的计算问题，可以解决复杂问题但非常困难（而Hibernate是完全不能）。SP的出现并不能有太大的改善。代码难以拆分，复杂目标难以分解为简单步骤是主因。
　　大数据支持：1星。个别数据库厂商表示已经支持大数据了，但这让SQL语句的不兼容程度加剧了，而且我也没见过成功案例。
　　非数据库计算：1星。不直接支持。采用ETL/数据仓库可以达到这个目的，但代价巨大。
　　跨库计算：1星。个别数据库支持，但性能较差，也可以采用DBLink和link server等中间件勉强支持，但离“自由方便”的程度还差得远。
　　调式方便性：1星。很难调试，难以观察中间结果，只能全部执行完才能看到终计算结果。的办法是“以调试为目标进行编程”，即刻意建造大量临时表。
　

　iBatis:
　　简单敏捷因此强大的数据计算层。和Hibernate不同，它鼓励写SQL，所以学习成本低。同时它用小的代价实现了计算脚本和JAVA代码的解耦，只用20%的代价实现了hibernate 80%的功能。另外没实现的20%是计算脚本和数据库的解耦。
　　复杂计算环境是它的弱项，比如：分布式计算、复杂计算、非数据库计算、跨库计算。
　　成熟度:4星。iBatis经过了十几年市场的考验，是我喜欢的框架之一。但对缓存的支持不足仍然是缺陷。
　　低耦合性：2星。SQL可以无缝替换，但仍然是针对具体数据库的SQL。事实上后者是数据库的问题，厂商要粘住客户，所以SQL不兼容，让你难以迁移；但程序员不愿让粘住，非要迁移。
　　脚本编写：3星。它是SQL。
　　集成：4星。基本没有难度，初学者半天时间都可以熟练掌握。
　　界面友好性：4星。没有图形化计算过程设计界面，但可以借用SQL工具。
　　性能：3星。性能比SQL略低，主要是resultSet和map/list之间转化需要多花费一点时间。另外缓存支持不如hibernate好。综合比起来两者区别不大。其实我认为引入ORM的同时引入性能问题是失败的。
　　复杂计算：3星。同SQL，比hibernate强。
　　大数据支持：1星。同SQL
　　非数据库计算：1星。同SQL
　　跨库计算：1星。同SQL
　　调式方便性：1星。同SQL


　　R语言
　　R语言不易和JAVA集成，但强大的计算能力和广泛的社区支持，以及大数据的特性使我不得不提到它。另外跨库的计算、非数据库的计算、模型计算也是它的强项。当然，在各种数据计算层中，它也是难学习的。
　　成熟度：5星。R语言的历史仅次于SQL。无数的社区在热烈讨论R。尤其是大数据时代。
　　低耦合性：4星。R语言和集算器在这方面没区别。
　　脚本编写：3星。这方面R和集算器很像，区别是集算器更敏捷代码更灵活，对结构化数据的支持更专业，而R内置了大量模型算法。所以基本持平。
　　集成：1星。R不是JAVA架构，很难集成进JAVA，本来性能不高，集成后性能更是大幅度降低。
　　界面友好性：3星。有专门的IDE界面，但很粗糙，实际价值不大，这也是开源产品的通病。
　　性能：2星。全内存运算，难以应付大数据量。
　　复杂计算：5星。同集算器类似。
　　大数据支持：3星。有R与Hadoop的结合机制，但JAVA体系与非JAVA体系之间的结合并不容易，性能损失较大。
　　非数据库计算：5星。同集算器类似。
　　跨库计算：5星。同集算器类似。
　　调式方便性：2星。勉强算有调试功能，但很不专业。