最近懒的一逼，啥都不想干，开个贴记录一下，开发一个玩具库，会遇到哪些坑，以及填坑的过程有哪些。

下面开始具体设计流程了。
1：需求分析
2：技术选型
3：怎么实现

这个库，到底能解决，哪些问题呢？
这个得从一个奇怪的现象说起。
也就是写sql问题。
在日常开发中，要么用mybatis，jpa，jdbcTemplate之类的技术，他们都有一些特征。
也就是极大的的简化了，日常crud操作。
也就是，如果你只要，单表查询有关的，那么，你基本就不用写啥代码，就完成任务了。
如果设计到，多表join之类的操作，那么就可能头疼了。
如果刚好时，多表join之后，在group一下，那么就更头疼了。

然而这个问题，还没有结束。
他的下一个版本时，字段格式化group问题。
也就是典型，报表相关的，将日期格式化到年月日后，再group求年月日报表。
然而这还没结束，他继续有新的版本。
在数据量大了之后，你按这个group统计的方法，会跑的很慢的。
然后他怎么解决呢？
创建临时表，然后把查询的数据，导入这个表里面去，按定时任务的方式，定时丢数据到里面去。

因此，目标就是一些简化以上业务操作的db库，目标就是为了，极大简化写sql的流程。
用配置化的方式，实现复杂sql的编写。

工程目录截图：
我们新建一个项目，名字随便起
base模块，基础定义模块
core模块，依赖base，实现核心业务的模块

既然说，要极大的简化sql操作，甚至要超越mybatis plus这种库，那么自然要有一些特殊的技巧，来使得这个库。
比别人家的更好用，这里我选择的方式是，注解。
是的，任何sql操作，都是基于类的注解完成的
也就是典型的，实体即sql
下面看看核心注解有哪些

下面用注解来配置下，具体demo例子

刚才的是单表的演示，那么，多表也能用吗？
当然，下面演示，多表join例子
举个例子，你想统计，部门每个月新进人数有多少
假设有sys_user 用户表 ,sys_dep 部门表

JoinTableList 表明列表，主要在里面嵌套JoinTable，进而实现多表join
单元测试，这次不赋值了

下面是sql，一样丢到数据库运行看看是不是可以的

好像还能跑哦，多表join也是可以的。
并且注意到，当字段有值，他就按JoinWhere 哪里配置的条件，
根据上下文，动态的丢到where 或者 having 哪里去，

继续开始更。
回顾之前的能力，我们做到的什么呢？
单表，多表的join动态sql拼接，
单表，多表的join聚合。
在这里，我们抽象个概念，sql实体。
定义，类加了JoinTable或者JoinTableList 注解的，都是sql字段
sql字段，加了JoinField 字段的，简称sql字段。

我们观察下，mybatis 之类的框架，他们有个实体概念
叫做，一对一，一对多概念
在传统的写法里，我们是怎么写的呢？
我们会写2个方法，在其中一个方法里，调用另外一个方法，完成一对多之类的数据注入
也就是说，复杂度，比之前复杂了。

我们举个例子，部门，用户，一个部门下面有多个用户
假设有sys_user 用户表，sys_dept部门表。
我们定义sql实体
用户实体

部门实体

我们看到了一个新的注解
JoinQuery，我们定义，提示一个自动查询，根据当前实体，自动做数据注入用的。
他在查询sys_user 的sql ，应该是，from sys_user where sys_dept_id = #{id}
#{id} 当前实体的id值
他是实现自动一对一，一对多概念用的。