在ddl test中有一段save(Table)的测试 正常情况下在保存时会检测数据库中的主键，与table中的主键是否一致，如果不一致会修改，大部分库是先删除旧的主键，再创建新的主键。 这就涉及到一个查询主键的SQL 如果这个SQL不正确，那当然下一步比较也会出问题。 如kingb

1.不利于抽象设计。 比如要设计一个求和的函数。如果基于实体Bean应该类似这样sum(List beans, "属性")，很明显需要动用反射，在几条数据的测试环境一性能可以接受，但在生产环境中就不一样了。 2.不利于数据拆分 比如只需要查询或保存ID,NAME两个属性时，整个实体作为参数传过来，又需要反射，需要挨个判断。

以MySQL(关系型)、Milvus(向量库)、MongoDB(文档型)、Neo4j(图库)、ElasticSearch(搜索型)为例，从操作对象(如创建表）、插入数据、查询数据三个流程对比说明，如果实现service层面方法及参数的统一。

主要用来配置从结果集中读取元数据的依据，如表名，列名，数据类型等在结果集中的哪一列 从每个adapter中实现的方法中返回如TableMetadataAdapter/ColumnMetadataAdapter/IndexColumnMetadataAdapter 注意这里只能设置从哪一列读取数据，但

MATCH (n:User) RETURN n; [ {n:{id:1,name:''}}, {n:{id:2,name:''}}, {n:{id:3,name:''}} ] 而 service.querys("User"); 返回 [ {id:1,name:''}, {id:2,name:''}, {id:3,name:''} ]

DataSourceHolder  主要用来创建数据源  Adpater  每种数据源对应一个Adapter,主要用来针对不同的数据库生成当前数据库可执行的命令，屏蔽不同数据库的命令差异及数据类型的兼容。实现以相同的语法操作不同数据库，读写表结构、索引等元数据表结