关系：两端与基数

关系有两端，一条就够

上一门课把示例工厂的对象类型建好了，这一门给它们连线。关系（Link Type）是两个对象类型之间的关系定义；链接（link）是这个关系的一个实例，比如「客户甲有订单 SO-1001」这一条。把它想成数据库里的 join：关系是 join 的定义，链接是 join 出来的一行。

每个关系有且只有两端，每一端有自己的名字。名字要读起来像一句话：从客户出发叫 orders，从销售订单出发叫 customer。一条定义，两头都能走，所以不要再为反方向另建一条关系。取名的办法是问自己：站在这一头，人会怎么说？「这家客户的订单」就是 orders，「这张订单的客户」就是 customer。

同一对对象类型之间可以有几个关系，前提是每个都是不同的业务事实。两条规则在定义时检查：同一个对象类型上，链接端的名字不能重复；链接端的名字也不能和这个类型自己的属性同名，因为链接和属性共用一个命名空间。所以订单上的外键属性叫 customerId，链接端叫 customer。

基数决定怎么存

基数说的是每一端最多对应几个对象，它同时决定这条关系存在哪里。

foreignKey.side 写的是哪一头持有外键属性：客户到订单，订单持有，所以是 to；订单行到产品，订单行持有，所以是 from。外键属性必须真的存在，类型要和被引用的主键一致；找不到它，整批定义会被拒收。

一个常见的坑：把一对一当成「唯一约束」。它只表达意图，两个对象的外键指向同一个对象，也不会被拦下。真要保证唯一，就在写入的那个 Action 里加一条提交条件。

[
  {
    "kind": "linkType",
    "apiName": "customerOrders",
    "title": "Orders of a customer",
    "schema": {
      "from": "customer",
      "to": "salesOrder",
      "cardinality": "ONE_TO_MANY",
      "apiNameAtoB": "orders",
      "apiNameBtoA": "customer",
      "foreignKey": { "side": "to", "property": "customerId" }
    }
  },
  {
    "kind": "linkType",
    "apiName": "orderLineProduct",
    "title": "Product of an order line",
    "schema": {
      "from": "orderLine",
      "to": "product",
      "cardinality": "MANY_TO_ONE",
      "apiNameAtoB": "product",
      "apiNameBtoA": "orderLines",
      "foreignKey": { "side": "from", "property": "sku" }
    }
  }
]

多对多：链接自己也有属性

物料清单（BOM）是最典型的多对多：一个产品用多种物料，一种物料也用在多个产品里。「每台用多少」既不属于产品，也不属于物料，它属于这一对产品和物料。所以它是链接上的属性 quantityPerUnit。

{
  "kind": "linkType",
  "apiName": "productMaterials",
  "title": "Bill of materials",
  "schema": {
    "from": "product",
    "to": "material",
    "cardinality": "MANY_TO_MANY",
    "apiNameAtoB": "materials",
    "apiNameBtoA": "products",
    "columns": [
      { "name": "quantityPerUnit", "type": "decimal", "title": "Quantity per unit" }
    ]
  }
}

• 链接属性写在 columns 里，类型照属性的 base type，最多 16 个。
• 一对产品和物料只有一条链接，由两端的主键定位。
• 把 quantityPerUnit 放到 material 上是常见的错：同一种物料在不同产品里用量不同。

改关系也只走 Action。多对多用 createLink 和 deleteLink；外键关系改外键属性就行，给订单换客户，就是用 modifyObject 改 customerId。普通规则只改语义层。若 Action 配置了 webhooks.writeback，它会先调用 ERP，再执行规则。ERP 拒绝或超时，语义层不改。

下一节沿着这些关系走：从一个订单走到它的订单行，一批一批地换类型，最后读出 BOM 上的用量。