为什么要使用新一代ORM框架sqltoy-orm

sqltoy-orm是基于java的最综合最理想的orm框架，主要特点：

1、是真正超越hibernate/jpa、jdbcTemplate、mybatis/plus、jooq之和的orm框架，规避了上述框架的走极端的缺点，发挥他们的优势，即：普通的crud就应该类似于hibernate和jpa模式，查询就应该要比mybatis的查询还要强和简洁、高效、灵活！

2、hibernate/jpa 缺陷在于查询，mybatis的虽说优势是查询，但它的查询没有灵魂，就是死搬硬套，还耍花枪！看下面的图，这么大的差距看不出来！跟传统的if() {append()}有什么区别！

3、sqltoy-orm除了迎合了初学者关注crud之外，给大家带来了真正的项目需要的东西！

最值得吐槽的就是一些硬派技术者，强调框架就是框架不应该带入一些场景，比如说:缓存翻译、分页极度优化，取top、取随机记录、树结构表查询、行列旋转、同比环比、分库分表、超大规模数据处理等。

而我认为：框架就应该提供针对最实用的场景提供快捷的方式、针对最艰难的环节提供解决方案，不让ORM成为彼此的鸿沟，装X的利器。使用sqltoy-orm就可以荡平大多数人在orm层的技术差距！

• 有没有被问过mybatis如何分页？
• 有没有被问过mybatis plus的接口是如何变成了最终实现的?
• 有没有被问过如何解决大规模数据查询性能问题？

sqltoy则完全演绎了从普通crud、再遇到复杂查询、再到大规模数据使用分库分表、再到超大规模数据引入elasticsearch、clickhouse 、mongodb采取针对性的应对的绝大多数场景经验的融合！

• sqltoy 之最强分页：

1. @fast() 实现先局部分页提取单页数据再关联，减少关联数据的规模提升效率
2. page-optimize：利用缓存机制，避免在短时间内每次都执行count查询

注：不要等同于二级缓存概念，分页优化一般强调较短周期内用户点下一页，减少count查询。

<!-- 快速分页和分页优化演示 -->
<sql id="sqltoy_fastPage">
	<!-- 分页优化器,通过缓存实现查询条件一致的情况下在一定时间周期内缓存总记录数量，从而无需每次查询总记录数量 -->
	<!-- alive-max:最大存放多少个不同查询条件的总记录量; alive-seconds:查询条件记录量存活时长(比如120秒,超过阀值则重新查询) -->
	<page-optimize alive-max="100" alive-seconds="120" />
	<value>
		<![CDATA[
		select t1.*,t2.ORGAN_NAME 
		-- @fast() 实现先分页取10条(具体数量由pageSize确定),然后再关联
		from @fast(select t.*
			   from sqltoy_staff_info t
			   where t.STATUS=1 
			     #[and t.STAFF_NAME like :staffName] 
			   order by t.ENTRY_DATE desc
			    ) t1 
		left join sqltoy_organ_info t2 on  t1.organ_id=t2.ORGAN_ID
			]]>
	</value>
	
	<!-- 这里为极特殊情况下提供了自定义count-sql来实现极致性能优化 -->
	<!-- <count-sql></count-sql> -->
</sql>

• sqltoy的缓存翻译，大幅减少表关联

• 写sql做数据旋转困难吗？会吗？写一大堆极其复杂的sql有必要吗？

今天就讲到这里，虽然作者用词有点看似骄傲其实是很谦虚的，是因为sqltoy的发展一路走来真不容易，大家都懂国人极为崇洋媚外！

很多人说我是在宣传sqltoy，其实不仅仅是这样，我更希望用sqltoy-orm荡平所有开发者在数据库交互层之间的技术差距，专心于其他领域！

开源地址：

• github: https://github.com/chenrenfei/sagacity-sqltoy
• gitee: https://gitee.com/sagacity/sagacity-sqltoy
• idea 插件(可在market直接检索sqltoy安装): https://gitee.com/threefish/sqltoy-idea-plugins