陀螺匠子实体关联配置指南：低代码平台中的实体关系建模

最近有朋友问我，陀螺匠这种低代码平台里的子实体关联到底怎么搞，是不是非得写SQL、加外键不可。当时他要做的是一个很常见的业务：客户下单，一笔订单里有多条商品明细，又想以客户为主入口，随时把订单和明细拉出来看。他并不是程序员，之前习惯用Excel登记一切，看到“实体”两个字就有点发怵。

我告诉他，子实体关联在低代码平台里并不等于传统数据库建模，它只是把“外键关联”这个开发概念藏到了配置界面背后。陀螺匠这类产品要解决的正是这件事：让不写后端代码的人也能完成实体设计、关系设置和页面生成，最后得到一个真正能跑的后台系统。这篇内容适合两类人看。一类是刚接触陀螺匠、准备用它搭建业务管理系统的人；另一类是已经用了低代码一段时间，却一看到实体、父表、子表就头疼的技术小白。下文不会堆数据库术语，最多用几张表格说明关系，尽量按我实际配置的过程来写。

1. 先把基本盘想清楚：实体、子实体和关联到底是什么

1.1 实体，像Excel表格，但比Excel表格守规矩

初用低代码平台时，看到“实体”两个字总会先一激灵。其实完全可以不用怕。实体在陀螺匠里的角色，非常接近Excel里的一张sheet，也接近数据库里的一张表。比如你要做客户管理，就可以在实体管理里建一个“客户信息”，客户名称、联系电话、所属区域都是这个实体的字段，字段类型可以定义为文本、日期、数字、下拉选项等。

但与Excel不同的是，实体带有明确的字段类型，还能定义必填、唯一、默认值、是否逻辑删除。好处在于，平台可以靠这些定义自动生成数据表和增删改查接口，不需要你去安装数据库、写建表语句。可以这么理解：后台有多少个业务对象，通常就会建多少个实体。客户是一个实体，订单是一个实体，商品也可以是一个实体。

有些朋友第一次打开实体列表时会被“租户”“逻辑删除”“审计字段”这些陌生开关吓到，其实不必急着全搞懂。先把“实体是业务对象的容器”记住，后面的内容都不会太偏。需要提醒的是，低代码平台之间的术语并不统一，有的叫“数据模型”，有的叫“业务对象”，陀螺匠大量资料里用的是“实体”，含义是一样的。学习时不要太纠结界面按钮叫什么，关键是理解这张“表”会和谁产生关系、被谁引用。

1.2 子实体和关联，不是一个功能，而是一组关系

“子实体关联”可以拆成“子实体”和“关联”两部分来看。子实体是相对主实体而存在的：订单明细相对于订单就是子实体，订单相对于客户也是子实体。而“关联”是告诉平台，两张表里的记录怎么找到彼此。传统开发里，最常用的做法是在子表加一个外键字段，保存主表那行记录的ID；在陀螺匠里，这个加外键的操作被封装成了“新建一个关联字段”或者“在关联设置里指定主从实体”。

拿最经典的客户—订单—订单明细来举例。客户在最上层，属于最稳定的主数据；订单相对客户是子，但相对订单明细又是父；订单明细在最底层。这个层级结构不要求你从零去学SQL里的join查询，但要求你理解记录归属：一条订单明细一定归属于某个订单，一个订单一定归属于某个客户。谁能提供归属关系，谁就要负责记住上一级记录的ID。

很多技术小白把“加关联”想象成一种神奇魔法，实际它做的事情很朴素：比如在订单明细表里存一个order_id，看到某条明细数据时就能反查它属于哪一单。你可以把这个过程类比成工牌上的部门编号，员工要找到自己部门，不需要把部门所有人名字都写在工牌上，只写部门编号就够了。把“谁归属于谁”的角色理顺，后面配置界面就只是点几个下拉框的事。

1.3 那为什么技术小白也能搞定，不会写代码也没问题

实话讲，实体关联在传统开发流程里非常劝退，因为建表、外键、接口、页面全是独立环节，任何一个环节都需要专业人士。陀螺匠这种低代码平台把整套流程压成了一个主线：建实体填字段，设置关联关系，一键生成接口和页面。这个抽象让“写后端代码”这件事从必选项变成了可选项，所以技术小白才有机会碰实体关联。

但这里也要把丑话说在前面。低代码不等于零思考，只是把“会不会写代码”的难度降下来了，并没有把“懂不懂业务”的难度降为零。我见过有人为了省事，把客户名称字段直接复制到一张非常宽的Excel式实体里，里面挤了订单号、商品名、数量、金额，客户改一次名就要批量去改历史数据。短期能用，长期就是给自己挖坑。下面所有实操，都是围绕“先建对实体关系”来展开的，这比记住任何按钮位置都重要。

2. 配置关联之前，先把这三类业务关系想清楚

2.1 一对一、一对多、多对多，分别什么时候用

我接触过很多低代码新手，一上来就急着点“新建实体”，然后凭感觉加字段。其实实体模型设计的核心不是“一张表长什么样子”，而是“表与表之间是什么关系”。我的建议是，先别打开后台，拿纸