4、数据模型设计：实体定义、字段类型、关系映射、数据源配置

好，咱们进入第四章。数据模型设计，说白了就是低代码平台的“地基”。你盖楼，地基没打好，后面装修得再漂亮也得塌。我在做第一个低代码项目时，就吃过这个亏——当时急着上线，实体关系没理清楚，结果后期客户要加个“多对多”关联，差点把整个数据库重构了一遍。嗯，从那以后，我再也不敢轻视这一步了。

4.1 实体定义：一切业务的核心

实体是什么？说白了就是你要管理的“东西”。比如一个CRM系统，客户、订单、产品，这些都是实体。在低代码平台里，实体定义就是告诉系统：“嘿，我要管这些数据，你帮我建个表。”

我个人习惯，定义实体时先问三个问题：

  • 这个实体是独立的吗？ 比如“客户”就是独立的，“订单明细”通常依赖“订单”。
  • 它有哪些核心属性？ 别一上来就列几十个字段，先抓关键的。
  • 它跟其他实体怎么关联？ 一对一？一对多？多对多？

举个例子，一个简单的“员工”实体：

{
  "entityName": "Employee",
  "displayName": "员工",
  "fields": [
    { "name": "name", "type": "string", "label": "姓名" },
    { "name": "email", "type": "string", "label": "邮箱" },
    { "name": "departmentId", "type": "relation", "label": "所属部门" }
  ]
}

你看，这里我只定义了三个字段。为什么？因为一开始别贪多，后面可以慢慢加。我在项目中见过有人一口气定义50个字段，结果一半都用不上，反而拖慢了页面加载速度。

小技巧： 实体名称建议用英文驼峰命名，显示名用中文。这样后端代码生成时可以直接复用，前端展示也友好。

4.2 字段类型：别小看这个选择

字段类型，听起来简单吧？字符串、数字、日期……但你真的选对了吗？

我遇到过最坑的事：有人把所有字段都定义成“字符串”。结果呢？排序时“10”比“2”小，日期比较全乱套。你想想看，这能不出问题吗？

低代码平台里，常见的字段类型我列一下：

类型 说明 使用场景
string 字符串 姓名、描述、备注等
number 数字（整数/浮点） 价格、数量、年龄
boolean 布尔值 是否启用、是否删除
date 日期 创建时间、生日
datetime 日期时间 订单时间、操作日志
enum 枚举 状态（待审核/已通过/已驳回）
relation 关联关系 外键、多对多关联
json JSON对象 扩展属性、动态配置

这里我要特别说一下 enum 类型。很多新手喜欢用字符串存状态，然后在代码里写死“0=待审核，1=已通过”。这其实很危险——一旦业务变了，你得改代码。用枚举类型，平台会自动生成下拉选项，改起来也方便。

注意： 别滥用 json 类型。虽然它很灵活，但查询性能差，索引也不好建。我一般只在“扩展属性”这种场景才用。

4.3 关系映射：把数据串起来

实体之间怎么关联？这是低代码平台的核心能力之一。你想想看，一个订单没有客户信息，那还叫订单吗？

关系映射有三种基本类型：

  • 一对一： 比如一个员工对应一个工位。很少用，但某些场景很关键。
  • 一对多： 一个部门有多个员工。这是最常见的。
  • 多对多： 一个学生可以选多门课，一门课也有多个学生。需要中间表。

在低代码平台里，我们通常这样配置：

{
  "relations": [
    {
      "type": "oneToMany",
      "sourceEntity": "Department",
      "targetEntity": "Employee",
      "foreignKey": "departmentId"
    },
    {
      "type": "manyToMany",
      "sourceEntity": "Student",
      "targetEntity": "Course",
      "throughEntity": "StudentCourse"
    }
  ]
}

我曾经在一个项目中，客户要求“一个订单可以关联多个客户”。这听起来有点反直觉，但业务确实需要——比如一个家庭共同购买。这时候，多对多关系就派上用场了。

嗯，这里要注意：关系映射不要搞得太深。我见过有人把实体关联了七八层，结果查询时性能惨不忍睹。一般来说，三层以内就够了。

4.4 数据源配置：让数据流动起来

数据源配置，说白了就是告诉平台：“你的数据存在哪里？怎么连？”

低代码平台通常支持多种数据源：

  • 内置数据库： 平台自带的，开箱即用。适合小项目或原型开发。
  • 外部数据库： 比如 MySQL、PostgreSQL、SQL Server。适合企业级应用。
  • API 数据源： 通过 RESTful 接口获取数据。适合对接第三方系统。
  • 文件数据源： Excel、CSV 等。适合临时导入导出。

我个人建议，生产环境一定要用外部数据库。为什么？因为内置数据库通常性能有限，而且不好做备份和迁移。我之前有个客户，用内置数据库跑了半年，数据量一上来，查询慢得像蜗牛。后来迁移到 MySQL，问题才解决。

配置示例：

{
  "dataSource": {
    "type": "mysql",
    "host": "192.168.1.100",
    "port": 3306,
    "database": "lowcode_demo",
    "username": "admin",
    "password": "encrypted_password",
    "poolSize": 10
  }
}
核心要点： 密码一定要加密存储！我见过有人直接在配置文件里写明文密码，结果被运维同事骂惨了。用 AES 或 RSA 加密，平台启动时再解密。

另外，数据源配置里还有一个容易被忽略的点——连接池。别小看这个参数，设得太小，高并发时数据库会崩；设得太大，资源浪费。我一般建议根据业务量来，初期设 10-20 个连接，后面再调优。

4.5 避坑指南：我踩过的那些坑

最后，分享几个我亲身踩过的坑，希望能帮你少走弯路：

  • 字段命名不规范： 我曾经用中文做字段名，结果生成 SQL 时各种报错。后来统一用英文小写+下划线，再也没出过问题。
  • 忽略索引： 有个项目上线后，查询越来越慢。一查，发现所有字段都没建索引。后来给常用查询字段加了索引，速度提升了 10 倍。
  • 关系映射循环引用： A 引用 B，B 引用 C，C 又引用 A。序列化时直接栈溢出。解决办法是加一个“深度限制”或“忽略循环”。
  • 数据源切换不灵活： 开发环境用 SQLite，生产环境用 MySQL，结果 SQL 语法不兼容。建议从一开始就用同一类数据库，或者用 ORM 做抽象层。

好了，这一章的内容就到这里。数据模型设计看似基础，但决定了整个平台的成败。下一章我们会聊“页面设计器”，到时候你会看到，数据模型定义得好，页面搭建起来有多爽。

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