• 动态、运行时
  即运行时才能最终确定 动态的数据源、数据结构、展现形式
  如我们需要开发一个数据中台或者一个数据清洗插件，编码阶段我们还不知道数据来源、什么类型的数据库甚至不是数据库、会有什么数据结构对应什么样的实体类，
  如果需要前端展示的话，更不会知道不同的终端需要什么各种五花八门的数据组合
  那只能定义一个高度抽象的实体了，想来想去也只有Collection<Map>可以胜任了。
  
  
• 简单快速的操作数据库
  最常见的操作：根据条件分页查询一个表的几列
  这一动就要倾巢出动一整套的service/dao/vo dto 各种O/mapper，生成个查询条件各种封装、为了拼接个SQL又是各种if else forearch
  如果查询条件是由前端的最终用户动态提供的，那Java里if完了还不算完，xml中if也少不了
  一旦分了页，又要搞出另一套数据结构，另一组接口，另一组参数(当然这种拙劣的设计只是极个别，不能代表ORM)
  
  
• 简单快速的操作结果集
  数据库负责的是存储，其结构肯定是与业务需要不一样的。所以结果集需要处理。当我们需要用Map处理数据或数学计算时，
  如最常见的数据格式化、筛选、分组、平均值、合计、方差等聚合计算、
  再如空值的处理包括,"",null,"null","\n","\r","\t","   "全角、半角等各种乱七八糟的情况;
  这时就会发现Map太抽象了，除了get/set/forearch好像也没别的可施展了。
  要处理的细节太多了，if都不够用了。
  
  
• 动态数据源
  再比如多数据源的情况下，要切换个数据源又是IOC又是AOP一堆设计模式全出场。经常是在方法配置个拦截器。
  在同一个方法里还能切换个数据源了？
  数据中台里有可能有几百几千个数据源，还得配上几千个方法？
  数据源是用户动态提交的呢怎么拦截呢？
  这不是DB Util的本职工作么，还要借助其他？
  哪个项目少了AOP依赖还切换不了数据源了？
  
  
• 重复工作
  如果只是写个helloworld，以上都不是问题，没什么解决不了的。但实现工作中是需要考虑工作量和开发速度的。
  比如一个订单可能有几十上百列的数据，每个分析师需要根据不同的列查询。有那么几十列上同时需要<>=!=IN FIND_IN_SET多种查询方式算正常吧
  不能让开发人员挨个写一遍吧，写一遍是没问题，但修改起来可就不是一遍两遍的事了
  所以需要提供一个字典让用户自己去配置，低代码开发平台、自定义报表、动态查询条件应该经常有这个需求。
  当用户提交上来一个列名、一个运算算、一组值，怎么执行SQL呢，不能在代码中各种判断吧，如果=怎么合成SQL，如果IN怎么合成SQL
• 多方言
  DML方面hibernate还可以处理，DDL呢？国产库呢？小众库呢？
  比如作一个异构数据库迁移工具，还能要求用户熟悉每种数据库的语法？是不是应该让用户提供几个参数自动生成就可以了。
  比如提供*表示同步所有表，*-T1,T2表示同步除了T1,T2之外的所有表，不能让用户为每个表针对不同的库写不同的SQL吧。

当然这种问题很难有定论，只能在实际应用过程中根据情况取舍。以参考【适用场景】和【实战对比】中的示例