4、数据模型设计：实体与字段设计、关系建模、数据源配置与数据绑定

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

我见过太多项目，前期图快，随便拖几个字段就开始搭页面。结果业务一复杂，数据乱成一锅粥，改都改不动。嗯，今天我们就来聊聊，怎么把这个地基打扎实。

4.1 实体与字段设计：别把字段当Excel列来用

很多新手容易犯一个错：把低代码的「实体」当成Excel表格来设计。字段名随便起，类型随便选。我个人习惯是，在设计实体之前，先问自己三个问题：

  • 这个实体代表什么业务对象？（比如「订单」、「客户」、「商品」）
  • 这个对象有哪些核心属性？（比如订单有「金额」、「状态」、「下单时间」）
  • 这些属性之间有没有依赖关系？（比如「总金额」是不是由「单价×数量」算出来的？）

字段类型的选择，我建议遵循一个原则：用最严格的类型，存最准确的数据。

字段类型 适用场景 避坑提醒
文本 名称、描述、备注 记得限制长度，别让用户输入几万字
数字 金额、数量、年龄 金额用「小数」类型，别用「整数」
日期/时间 创建时间、到期日 统一用时间戳，别存字符串
布尔 是否启用、是否删除 别用「0」和「1」代替，语义不清晰
枚举 状态、类型、级别 枚举值要稳定，别频繁改
⚠️ 我曾经踩过一个坑：有个项目把「订单状态」设计成文本字段，结果前端展示时，有的写「已支付」，有的写「支付成功」，有的写「paid」。数据一查，乱得没法看。后来全部改成枚举，才消停。

4.2 关系建模：一对一、一对多、多对多

实体之间的关系，是数据模型的灵魂。你想想看，如果「订单」和「客户」之间没有关联，那订单是谁下的都不知道。

4.2.1 一对一关系

一对一，说白了就是一个萝卜一个坑。比如「用户」和「身份证信息」，一个用户只能有一个身份证，一个身份证只能属于一个用户。

实现方式很简单：在任意一张表里，加一个外键字段，指向另一张表的主键，并加上唯一约束。

-- 用户表
CREATE TABLE user (
  id INT PRIMARY KEY,
  name VARCHAR(50)
);

-- 身份证表
CREATE TABLE id_card (
  id INT PRIMARY KEY,
  card_number VARCHAR(18),
  user_id INT UNIQUE,  -- 唯一约束保证一对一
  FOREIGN KEY (user_id) REFERENCES user(id)
);
💡 我的习惯：一对一关系，我通常把外键放在「次要」的那张表里。比如身份证是用户的附属信息，就把外键放在身份证表。

4.2.2 一对多关系

这是最常用的关系。一个客户可以有多个订单，一个订单只能属于一个客户。实现方式就是在「多」的那张表里加外键。

-- 客户表
CREATE TABLE customer (
  id INT PRIMARY KEY,
  name VARCHAR(50)
);

-- 订单表
CREATE TABLE order (
  id INT PRIMARY KEY,
  amount DECIMAL(10,2),
  customer_id INT,
  FOREIGN KEY (customer_id) REFERENCES customer(id)
);

在低代码平台里，一对多关系通常表现为「主子表」或「关联列表」。比如在客户详情页，直接展示他的所有订单列表。

4.2.3 多对多关系

多对多关系，需要一张中间表来「搭桥」。比如「学生」和「课程」，一个学生可以选多门课，一门课也可以被多个学生选。

-- 学生表
CREATE TABLE student (
  id INT PRIMARY KEY,
  name VARCHAR(50)
);

-- 课程表
CREATE TABLE course (
  id INT PRIMARY KEY,
  title VARCHAR(100)
);

-- 中间表：选课记录
CREATE TABLE enrollment (
  student_id INT,
  course_id INT,
  enroll_date DATE,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES student(id),
  FOREIGN KEY (course_id) REFERENCES course(id)
);
🔑 关键点：中间表除了存两个外键，还可以存一些「关系本身的属性」。比如选课时间、成绩、是否退课等。这些属性既不属于学生，也不属于课程，而是属于「选课」这个关系。

4.3 数据源配置与数据绑定

模型建好了，怎么让页面用起来？这就涉及到数据源配置和数据绑定了。

4.3.1 数据源配置

数据源，就是告诉页面「你的数据从哪里来」。在低代码平台里，常见的数据源有：

  • 实体数据源：直接绑定到某个实体，自动生成增删改查接口
  • 视图数据源：基于多个实体关联查询，返回一个虚拟表
  • API数据源：调用外部接口获取数据
  • 静态数据源：写死的JSON数据，适合测试

我个人建议，能用实体数据源就别用API数据源。实体数据源自带权限控制、字段校验、关联查询，省心很多。

4.3.2 数据绑定

数据绑定，就是把数据源里的字段，映射到页面组件上。比如：

  • 一个「输入框」绑定到「客户名称」字段
  • 一个「下拉框」绑定到「订单状态」枚举
  • 一个「表格」绑定到「订单列表」数据源

绑定的时候，有几点要注意：

  • 双向绑定 vs 单向绑定：表单输入用双向绑定，展示列表用单向绑定
  • 数据格式转换：后端返回的时间戳，前端要转成「2024-01-01」格式
  • 空值处理：字段可能为空，页面要显示「--」或「暂无数据」
💡 一个小技巧：在低代码平台里，我习惯先建一个「测试页面」，把所有字段都拖出来展示一遍。看看数据对不对，格式对不对，关联对不对。确认无误后，再开始做正式页面。这一步能省下后面80%的调试时间。

4.4 总结一下

数据模型设计，其实就三件事：

  1. 实体与字段：用最严格的类型，存最准确的数据
  2. 关系建模：一对一、一对多、多对多，选对关系，用好外键和中间表
  3. 数据源与绑定：配置好数据来源，把字段映射到页面组件上

嗯，这一章的内容就到这里。下一章我们聊聊「页面布局与组件编排」，看看怎么把数据漂亮地展示出来。

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