第四章：数据模型设计——实体定义、字段类型、关系映射与元数据管理

数据模型设计，说白了就是低代码平台的“地基”。

你想想看，一个低代码平台，如果连数据都管不好，那上层搭出来的应用就是空中楼阁。我这些年做过的项目里，凡是后期出大问题的，十有八九是数据模型设计阶段埋下的坑。今天咱们就把这块掰开揉碎了讲清楚。

4.1 实体定义：一切从“对象”开始

实体是什么？就是业务中的“东西”。比如客户、订单、商品、员工。在低代码平台里，每个实体对应一张数据库表，也对应一个业务对象。

我个人习惯，在设计实体时先问三个问题：

  • 这个实体在业务中真实存在吗？
  • 它有没有独立的生命周期？
  • 它能不能被唯一标识？

举个例子，一个“订单”实体，它有创建、支付、发货、完成这些状态变化，有订单号作为唯一标识，那它就是一个合格的实体。但“订单备注”就不一定了——它更像是订单的一个属性，而不是独立实体。

我的经验： 别把“属性”当成“实体”。我在项目中见过有人把“手机号”单独做成一个实体，结果关联查询搞得一团糟。记住：实体是名词，属性是形容词。

在代码层面，实体定义通常长这样：

// 伪代码示例：实体定义
Entity order = new Entity("Order");
order.addField("orderNo", FieldType.STRING);
order.addField("totalAmount", FieldType.DECIMAL);
order.addField("status", FieldType.ENUM);
order.addField("createdAt", FieldType.DATETIME);

4.2 字段类型：选对类型，少走弯路

字段类型这事儿，看着简单，其实门道不少。低代码平台里常见的字段类型有这些：

类型 说明 我踩过的坑
STRING 字符串，最长255字符 有人把大段文本存成STRING，结果被截断了
TEXT 长文本，无长度限制 记得加全文索引，否则搜索慢到怀疑人生
INTEGER 整数 金额别用INTEGER，用DECIMAL
DECIMAL 高精度小数 精度和标度要设对，比如DECIMAL(10,2)
BOOLEAN 布尔值 有些数据库没有BOOLEAN，用TINYINT代替
DATETIME 日期时间 时区问题一定要处理，否则全球用户会骂你
ENUM 枚举 枚举值别写死，用配置表管理
FILE 文件/附件 存路径还是存二进制？我建议存路径

嗯，这里要注意：字段类型的选择直接影响存储和查询性能。我曾经接手过一个项目，所有金额字段都用FLOAT存，结果对账时差了0.01元，查了三天才发现是浮点精度问题。从那以后，金额类字段我统一用DECIMAL，绝不妥协。

4.3 关系映射：一对一、一对多、多对多

实体之间怎么关联？这就是关系映射要解决的问题。低代码平台里，关系映射通常有三种：

4.3.1 一对一（One-to-One）

一个用户对应一个身份证信息，这就是典型的一对一。实现方式很简单：在任意一张表里加对方的主键作为外键，并加上唯一约束。

// 一对一：用户和身份证
Entity user = new Entity("User");
user.addField("idCardId", FieldType.INTEGER); // 外键

Entity idCard = new Entity("IdCard");
idCard.addField("userId", FieldType.INTEGER); // 外键，加唯一约束
避坑指南： 我曾经见过有人把一对一设计成两张表共享同一个主键，结果数据迁移时差点崩溃。老老实实用外键，别玩花活。

4.3.2 一对多（One-to-Many）

一个客户有多个订单，这就是一对多。实现方式：在“多”的那张表里加“一”的主键作为外键。

// 一对多：客户和订单
Entity customer = new Entity("Customer");
// 不需要加字段

Entity order = new Entity("Order");
order.addField("customerId", FieldType.INTEGER); // 外键指向Customer

为什么外键加在订单表而不是客户表？你想想看，一个客户可能有成千上万个订单，如果外键加在客户表，那客户表得存一个数组，这在关系型数据库里是反模式。

4.3.3 多对多（Many-to-Many）

一个学生可以选多门课，一门课也可以被多个学生选。实现方式：需要一张中间表。

// 多对多：学生和课程
Entity student = new Entity("Student");
Entity course = new Entity("Course");

// 中间表
Entity studentCourse = new Entity("StudentCourse");
studentCourse.addField("studentId", FieldType.INTEGER);
studentCourse.addField("courseId", FieldType.INTEGER);
// 联合唯一约束：(studentId, courseId)
我的建议： 中间表不要只存两个外键。我习惯在中间表里加一些“关系属性”，比如选课时间、成绩、状态等。这样以后扩展起来特别方便。

4.4 元数据管理：让数据“活”起来

元数据是什么？就是“关于数据的数据”。在低代码平台里，元数据管理是核心中的核心。

说白了，元数据就是描述实体、字段、关系的那套“说明书”。平台运行时，不是直接操作数据库，而是先读元数据，再根据元数据动态生成SQL、表单、列表。

元数据通常包含这些内容：

  • 实体元数据： 实体名称、显示名、表名、是否启用、版本号
  • 字段元数据： 字段名、类型、长度、是否必填、默认值、校验规则
  • 关系元数据： 关系类型、关联实体、外键字段、级联策略
  • 索引元数据： 索引字段、索引类型、是否唯一

我见过最牛的元数据设计，是把元数据也存成一张表。这样平台启动时，只需要读一张表就能知道整个数据模型长什么样。而且修改元数据不需要重启服务，热加载就行。

// 元数据表结构示例
CREATE TABLE meta_entity (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  display_name VARCHAR(100),
  table_name VARCHAR(100),
  is_active BOOLEAN,
  version INT
);

CREATE TABLE meta_field (
  id INT PRIMARY KEY,
  entity_id INT,
  name VARCHAR(100),
  field_type VARCHAR(50),
  max_length INT,
  is_required BOOLEAN,
  default_value VARCHAR(255),
  validation_rule TEXT
);
我曾经踩过的坑： 元数据版本管理没做好，导致线上和测试环境的元数据不一致，数据迁移时出了大问题。现在我的做法是：每次修改元数据都生成一个版本号，并且记录变更日志。这样出了问题可以快速回滚。

4.5 总结与实战建议

数据模型设计这块，说难不难，说简单也不简单。我总结几条实战经验：

  • 实体命名要规范： 用驼峰命名，比如CustomerOrder，别用customer_order或者CustomerOrder123
  • 字段类型要精准： 能用DECIMAL就别用FLOAT，能用ENUM就别用STRING
  • 关系映射要清晰： 一对多就加外键，多对多就建中间表，别偷懒
  • 元数据要可扩展： 预留扩展字段，比如attributes JSON字段，方便以后加自定义属性
  • 版本管理要跟上： 每次改元数据都打版本，记录变更历史

嗯，数据模型设计这块就讲到这里。下一章咱们聊聊“表单引擎：动态表单生成与数据绑定”，到时候我会分享一些表单性能优化的实战技巧。

← 上一章 📖 返回目录 下一章 →