关于未知
未知不是绝对的什么信息都没有，而是一种超高的抽象。核心是将「未知」拆解为三个递进的层次，每一层都有对应的抽象与具象的应对机制，将「开发阶段不可预知的变化」转化为「运行时可通过元数据自动处理的确定性规则」。
核心策略：主动留白
MDM 应对「未知」的策略不是去预测未来，而是主动留白——将已知部分（稳定执行层）在开发阶段设计到极其稳定和通用，将未知部分（易变描述层）设计为完全由元数据驱动、在运行时动态填充。将「未知」从需要处处设防的威胁，转变为被严格限定在管理框架内的可控变量。
01场景未知 → 通用数据范式
将「不知道运行在什么数据库」坍缩为统一的操作标准
开发者在写代码时，完全不知道这段代码未来会运行在什么类型的数据库上。是 MySQL、Oracle，还是达梦、MongoDB？这不是「从A库迁移到B库」的确定性任务，而是根本性未知。
将所有数据库操作抽象为最顶层的通用数据范式——增删改查、建表改表、事务控制、元数据读取。运行时，动态方言引擎自动识别数据库类型，将标准操作转换为目标库的原生指令。
›运行时自动适配——同一份代码运行在不同数据库
系统在开发阶段就锁定这个稳定的执行层，不再需要为每种可能的数据库预置代码。这样，场景的未知就被限制在了已定义的抽象边界内——100+ 种数据库的差异，在方言引擎的自动转换下消弭于无形。
02结构未知 → 元数据模型
将「不知道表长什么样」坍缩为动态的元数据感知
代码运行时，所要操作的表结构、字段类型、约束关系都是动态的。低代码平台中用户随时新建表、添加字段；数据中台里接入的第三方数据源结构千差万别。
不再依赖静态的实体类，而是直接面向数据库的元数据编程。将「表、字段、索引、约束」抽象为统一的元数据模型，运行时通过采集器动态获取真实库结构并标准化。
›运行时动态感知表结构——无需预定义 Entity
所有具体的表结构变化，都被收敛到了这个稳定的元数据抽象层中。业务逻辑不再直接依赖物理表结构，而是依赖这个动态感知的元数据模型，从而实现了从「静态绑定」到「动态感知」的转变。
当用户在低代码平台新建一张表，或第三方系统推送了一个全新的数据源，元数据采集器会即时感知并标准化——业务代码无需任何修改。
03数据未知 → 动态数据容器
将「不知道查出什么数据」坍缩为自适应的数据承载
即使知道了表结构，每次查询返回的数据本身也是未知的。列的数量、类型都可能变化，甚至可能出现稀疏数据、动态列等情况。传统的强类型实体类无法承载这种不确定性。
提供通用的动态数据容器 DataSet/DataRow。不依赖任何预定义实体类，可以承载任意结构的数据。弱类型设计能自动适应结构变更，并内置类 SQL 的查询、聚合、过滤等计算能力。
›通用数据容器——自适应任意结构，容器内二次加工
数据内容的未知性被封装在了这个灵活的数据容器内部。无论返回多少列、什么类型、是否有空值——DataSet/DataRow 都能稳定承载，对未知结构数据的二次加工也在一个稳定、已知的接口下完成。
总结：设计上的主动留白
已知 · 稳定执行层
- 统一的操作接口
- 元数据抽象模型
- 动态数据容器 DataSet/DataRow
- 方言转换引擎
- 通用数据类型映射
开发阶段完全具象化的核心属性
未知 · 易变描述层
- 具体的数据库类型
- 动态表结构与字段
- 字段映射与约束关系
- 查询返回的数据内容
- 运行时环境变化
运行时由元数据动态填充
这种设计将「未知」从一个需要处处设防的威胁，转变为一个被严格限定在管理框架内的可控变量。它让系统不必在开发阶段预置一切，却能通过运行时动态加载的元数据，自动处理各类不确定性变化。
——这正是 AnyLine MDM 能够适应各类不确定性变化的根本原因