简介
AnyLine MDM的核心是一个面向运行时的 元数据动态映射
主要用来操作各种数据库结构以及读写元数据，已经适配100+数据库，300+正在路上
常用于动态场景的底层支持，作为SQL合成引擎或适配器出现
如:数据中台、可视化数据源、低代码、SAAS、自定义表单、异构数据库迁移同步、 物联网车联网数据处理、 动态表单、动态查询条件、 爬虫数据解析等。
愿景：
依托内置规则+外部插件合成方言转换引擎与元数据映射库
以此基础建立跨数据库的通用标准，实现异构数据库的统一操作
核心功能：
-
动态数据源管理
支持运行时动态注册、切换、注销各种不同类型数据源
提供七种数据源注册方式和三种切换机制
-
数据库结构和元数据管理
支持数据库结构的动态管理（如自动建表、字段扩展）和元数据的标准化采集（包括数据类型、注释、约束规则等），实现数据结构与元数据的统一治理
表结构差异对比
异构数据库结构复制及数据同步
-
动态DDL
基于元数据信息比对，分析表结构差异并生成跨数据库的动态DDL，支持字段类型映射、约束转换、索引等，常用于数据库迁移与版本同步。
-
动态查询条件
基于元数据的动态查询条件解决方案，实现灵活的数据筛选、排序和分页功能。
支持多层复杂条件组合、跨数据库兼容，可通过JSON、String、ConfigStore等多种格式自动生成查询条件。
尤其适合低代码平台，避免繁琐的判断、遍历、格式转换，同时保持高性能和可维护性。
-
数据库兼容适配
统一各种数据库方言 实现元数据对象在各个数据库之间无缝兼容
关系型、键值、时序、图谱、文档、列簇、向量、搜索、空间、RDF、Event Store、Multivalue、Object
特别是对于国产数据库的支持
-
对动态数据结构(DataSet<DataRow>)，内存计算
基于动态表达式引擎和类SQL过滤并内置各种数学计算公式，实现一键完成对结果集的聚合/过滤/行列转换等数学运算，避免传统ORM的繁琐遍历操作
-
多数据源事务管理
实现数据源任意切换 保持多个事务状态 支持跨线程事务
-
权限管理
对角色、用户、权限的管理
已经有了ORM了，为什么还要用AnyLine，两者有什么不同：
其中最显著的不同是：AnyLine主要是用来操作数据库结构(如自动合成、执行DDL)以及读写元数据(比如读出来的数据可以带数据类型、精度、约束、默认值等)
同时适配100+关系及非关系型数据库
-
一、面向场景不同
AnyLine：专为高度动态化的运行时场景提供底层适配，其核心优势在于对运行时不确定性的原生支持。
系统需要处理在任意时刻由不同用户发起的动态数据源接入请求，这些请求往往伴随着完全异构的数据结构和访问协议。
更关键的是，数据源的表结构、字段定义等元数据信息会随着业务需求或数据提供方的变化而实时调整。
通过动态元数据管理机制和自适应映射机制，能够在运行时感知变化，完成数据模型的动态重构和查询适配，实现"变化即常态"的动态支持能力。
传统ORM：更适用于静态或相对稳定的业务场景，其典型特征包括：在系统开发阶段即可明确定义数据库表结构、实体类关系等核心数据模型，且这些基础架构元素在后续运行维护过程中保持相对稳定，不会出现频繁的结构性变更。
能够充分发挥预定义架构的优势，通过前期完善的建模和设计，确保系统在稳定的环境中运行。
-
二、针对产品不同
AnyLine：主要定位于中间层开发平台，其典型应用场景是构建低代码平台、动态查询引擎等中间产品，而非直接开发面向终端用户的业务系统（如ERP、CRM等）。
通过动态建模和灵活配置能力，可以快速搭建业务工具平台，使最终用户能够自主创建满足个性化需求的业务应用，例如基于可视化配置的自定义查询分析工具，让业务人员无需编码即可按需生成动态报表和数据分析视图。
这种"平台赋能用户"的模式下，更能充分发挥AnyLine在动态适配和快速迭代方面的技术优势。
传统ORM：主要应用于终端业务系统的直接开发，如ERP、CRM、OA等企业管理软件。它通过对象关系映射技术，将数据库表结构映射为编程语言中的对象模型，使开发者能够以面向对象的方式操作数据库。特别适合业务模型相对固定的应用场景。
-
三、操作对象不同
AnyLine：采用元数据驱动的模式，其核心在于对数据结构和业务逻辑的抽象化处理。在项目初期阶段，当具体业务对象和属性尚未明确定义时，AnyLine通过元数据管理机制，允许开发者以动态配置的方式定义数据模型和业务规则。
使系统能够灵活适应业务需求的变化，支持用户在缺乏完整对象模型的情况下，通过元数据操作完成业务数据的设计、建模和交互。这种元数据优先的架构特别适合需求不确定或快速迭代的项目场景，为业务系统的渐进式开发提供了有力支撑。
传统ORM：核心在于操作与数据库表结构直接映射的实体类及其属性。通过建立对象模型与关系型数据库之间的映射关系，使开发者能够以面向对象的方式操作数据。
将数据库表映射为编程语言中的类，表中的字段对应类的属性，表间关系则通过对象间的关联关系来体现。特别适合业务模型稳定、数据结构明确的系统开发场景。
-
四、面向用户不同
AnyLine：主要面向系统架构师和底层框架开发者，特别适合需要构建高度灵活、可扩展应用系统的技术团队。它通过创新的动态元数据引擎和强大的结果集处理能力，为开发者提供了在运行时动态定义数据结构、业务规则和数据处理流程的能力。
有效解决传统开发中因需求变更导致的系统重构问题，使开发团队能够快速响应业务变化，特别适用于需要支持多租户、可配置业务模型的SaaS平台和低代码开发场景
传统ORM：主要服务于广大应用开发人员，特别适合需要快速构建和维护基于关系型数据库的业务系统的开发团队。通过实现对象与关系型数据库之间的自动化映射，使开发者能够完全以面向对象的方式进行数据库操作。
不仅大幅降低数据库访问层的开发难度，还显著提升系统的整体性能和开发效率。特别适合业务需求明确、数据结构相对固定的企业应用开发场景。
-
五、对用户要求不同
AnyLine：对用户(特别是设计人员)提出了更高的技术要求，主要面向具备系统架构思维的技术团队。需要用户深入理解元数据驱动开发理念，掌握动态数据模型的设计方法，并能够将业务需求转化为可配置的元数据规则。
这要求开发团队不仅要熟悉底层数据结构和业务逻辑，还需要具备动态系统设计经验，能够预见并处理运行时可能出现的各种业务场景变化。
传统ORM：则相对更易于上手和使用。ORM框架通过提供直观的映射关系和面向对象的数据库操作方式，降低了数据库操作的门槛。即使是没有丰富数据库操作经验的开发人员，也能通过ORM框架快速上手并开发出功能完善的应用系统。
-
六、设计理念与实现方式不同
-
动态 VS 静态
AnyLine：基于运行时元数据驱动，支持动态数据源注册（如用户运行时提供数据库地址/类型），无需预定义实体类或映射关系。
传统ORM：（如Hibernate）：依赖静态实体类与数据库表的预映射，需提前配置方言和表结构。
-
元数据操作 VS 对象操作
AnyLine：面向数据库结构（如表、视图、列等）和元数据(数据类型、长度、精度等)，适用于低代码平台或未知业务场景。
传统ORM：通过对象模型（Class/Property）间接操作数据库，需预先定义对象关系
-
多数据库适配
AnyLine：通过动态元数据引擎和智能方言适配，实现异构数据库的无缝兼容。内置200+种SQL语法转换规则，自动识别数据库类型并生成目标方言SQL，将不同数据库的元数据抽象为标准化对象，通过统一接口操作，实现元数据对象在各个数据库之间无缝兼容。
传统ORM：需硬编码实体类和方言，无法动态适配异构数据库的元数据差异和自动转换SQL语法，扩展性和兼容性受限。
-
动态 VS 静态
DataSet/DataRow vs 传统ORM实体类对比:
| 对比维度 | Anyline (DataSet/DataRow) | 传统ORM (Entity Class) |
|---|---|---|
| 数据表示方式 |
动态结构，类似内存数据库表（DataRow表示行DataSet表示表）
|
静态强类型类（如User.java）需预定义字段和类型
|
| 灵活性 | ✅ 动态适应表结构变更（如新增字段无需修改代码） | ❌ 表结构变更需同步修改实体类和映射配置 |
| 查询结果处理 | 直接操作动态结果集（支持动态聚合、行列转换） | 需通过DTO或投影接口转换查询结果 |
| 低代码支持 | ✅ 无需预知业务模型，适合动态表单和即席查询 | ❌ 需提前定义实体类，灵活性低 |
| 性能开销 | 轻量级，无反射和代理生成（直接操作元数据） | 可能因反射/字节码增强（如Hibernate代理）产生额外开销 |
| 复杂映射支持 | ⚠️ 默认手动处理(如多表JOIN结果)也支持各种ORM注解 |
✅ 自动管理关联（如@OneToMany）
|
| 适用场景 | 动态业务（如代代码、数据中台）、异构数据库操作 | 固定业务模型（如ERP、CRM） |
如何实现
解析层（自动将标准SQL语法转换为不同数据库的方言表达）
元数据抽象层（构建统一数据视图屏蔽结构差异）
多协议适配层（支持JDBC/ODBC/REST等混合协议接入）
使应用层能够以统一接口透明访问异构数据源，无需关心底层数据库类型、版本差异或分布位置，从而显著降低多源数据整合的技术复杂度
DataSourceHolder：用于动态管理多数据源的核心工具类，根据支持的协议每类数据源会有对应的DataSourceHolder。
DataRuntime：一个与数据源相关的上下文环境，其中关联了数据源、 数据库适配器、数据源及连接池参数、AnylineService等
DriverAdapter：主要用来生成命令，屏蔽不同数据库的命令差异及数据类型的兼容
DriverActuator：主要用来执行命令
ServiceProxy：主要用来管理Service切换数据源
DataSet/DataRow：主要用来封装数据并接收数据库返回数据，以及内存计算、格式转换
AnyLine提供了什么：
价值：
优势：
误解
当然我们并不是要抛弃Entity或ORM，不同的场景确实需要不同的解决方案，而 AnyLine 的设计理念正是为了提供灵活性和扩展性，同时不排斥传统的 Entity 或 ORM 使用。AnyLine 与 Entity/ORM 互补而非替代：
Entity/ORM 在 可预知、固定 的场景下具有强类型、编译时检查、代码可读性强等优势，适合业务逻辑稳定、数据结构明确的场景。
AnyLine 则专注于 动态、运行时 的场景，如数据中台、多数据源、动态查询条件、结果集灵活处理等，解决传统 ORM 在这些场景下的不足。
场景适配：
如果业务逻辑清晰、数据结构固定（如订单系统、用户管理等），使用 Entity/ORM 是更合适的选择。
如果业务逻辑复杂、数据源动态变化（如数据中台、报表系统、多租户系统等），AnyLine 的动态能力可以显著提升开发效率。
AnyLine 中的 Entity 使用：
AnyLine 的源码中确实使用了多个 Entity（如几何图形等），这说明 AnyLine 本身并不排斥 Entity，而是根据场景选择最合适的工具。
在 AnyLine 中，Entity 可以作为固定数据结构的载体，与动态数据源和查询条件结合使用，实现更灵活的业务逻辑。
如何选择合适的工具
分辨场景：
程序员需要具备分辨场景的能力，根据业务需求选择合适的技术方案。
对于固定场景，优先使用 Entity/ORM；对于动态场景，优先使用 AnyLine。
结合使用：
在实际项目中，Entity/ORM 和 AnyLine 可以结合使用，发挥各自的优势。
例如，使用 Entity/ORM 处理核心业务逻辑，使用 AnyLine 处理动态查询、多数据源切换等需求。
避免过度设计：
不要为了使用某种技术而强行适配场景，应根据实际需求选择最简单的解决方案。
AnyLine 的目标是降低开发复杂度，而不是增加复杂度。
如何集成
数据操作不要再从生成xml/dao/service以及各种配置各种O开始
只需要一个依赖、一个注解即可实现与springboot,netty等框架项目完美整合，剩下的交给默认的service。参考【入门系列】
关于数据库的适配
直接看示例(代码都是一样的、可以用来测试一下自己的数据库是否被支持)https://gitee.com/anyline/anyline-simple/tree/master/anyline-simple-data-jdbc-dialect
MySQL 
PostgreSQL 
Oracle 
SQL Server 
MariaDB 
Apache Hive 
IBM DB2 
clickhouse 
sqlite 
达梦 
tdengine 
derby 
H2 
hsqldb 
人大金仓 
OpenGauss 
Neo4j 
瀚高 
南大通用 
cassandra 
oceanbase 
神舟通用 
polardb 
questdb 
timescale 
SAP HANA 
SAP/MaxDB 
Voltdb 
Apache Ignite 
Apache Doris 
Apache IoTDB 
Vastbase(海量数据)
LightDB(恒生电子)
greatdb(万里数据库)
mogdb(云和恩墨)
GoldenDB(中兴) 
GaiaDB-X(百度云)
TiDB 
AntDB(亚信) 
citus 
TDSQL(TBase)(腾讯云) 
磐维数据库(中国移动)
CUDB(中国联通)
MuDB(沐融) 
HashData(酷克)
HotDB(热璞) 
UXDB(优炫) 
KunDB(星环) 
StarDB(京东) 
YiDB(天翼数智) 
UbiSQL(平安科技)
xigemaDB(华胜信泰)
SinoDB(星瑞格)
CockroachDB 
InfluxDB 
Informix 
MongoDB MogoDB 
RethinkDB
没有示例的看这个目录下有没有 【anyline-data-jdbc-dialect】还没有的请联系【技术支持】中的管理员
