EdgeDB中一对多反向引用查询限制的高效实现最佳实践

问题背景 #

现有如下抽象联系信息的EdgeDB Schema：

type Address {
   required property location -> str{
        constraint max_len_value(100);
    };
}

type Phone{
   required property number -> int32{
    constraint min_value(0);
    constraint max_value(9999999999);
   };
}

abstract type Contact {
    multi link address -> Address{
        constraint exclusive;
        on target delete delete source;
    };
    multi link phone -> Phone{
        constraint exclusive;
        on target delete delete source;
    };

}

type User extending Contact{
    required property name -> str{
        constraint max_len_value(40);
        constraint exclusive;
    };
    required property rank -> str{
        constraint max_len_value(40);
    };
}


type Worker extending Contact{
    required property name -> str{
        constraint max_len_value(40);
    };
    required property job -> str{
        constraint max_len_value(40);
    };

}

需求 #

对Address和Phone执行反向查询时，限制User只能查询关联到User的记录，Worker只能查询关联到Worker的记录（即不能将关联User的Address添加到Worker），该关系为一对多。

两种实现方案 #

方案一：使用反向链接（backlink）

type Address {
   required property location -> str{
        constraint max_len_value(100);
    };
    link in_user := .<address[is User]
    link in_worker := .<address[is Worker]
}

type Phone{
   required property number -> int32{
    constraint min_value(0);
    constraint max_value(9999999999);
   };
   link in_user := .<phone[is User]
   link in_worker := .<phone[is Worker]
}

方案二：使用类似SQL的外键链接

type Address {
   required property location -> str{
        constraint max_len_value(100);
    };
    link in_user -> User{
        on target delete delete source;
    };
    link in_worker -> Worker{
        on target delete delete source;
    };
}

type Phone{
   required property number -> int32{
    constraint min_value(0);
    constraint max_value(9999999999);
   };
    link in_user -> User{
        on target delete delete source;
    };
    link in_worker -> Worker{
        on target delete delete source;
    };
}

最佳实践结论 #

方案一（反向链接）是效率优先的最佳选择，核心原因如下：

• 存储无冗余：反向链接基于Contact已有的address/phone链接推导而来，不需要额外存储数据；方案二则要在Address和Phone中新增两个链接字段，产生冗余存储开销。
• 查询性能更优：EdgeDB对反向查询做了原生优化，会直接复用原链接的索引；方案二则需要维护两个独立的索引，查询时还要处理字段互斥的逻辑判断，增加查询复杂度。
• 数据一致性保障：反向链接由系统自动维护，不会出现数据不一致的情况；方案二中手动维护两个链接字段，容易出现误操作（比如同时给一个地址关联User和Worker），即便添加约束也会额外增加性能开销。
• 贴合EdgeDB设计范式：反向链接是EdgeDB处理关联反向查询的原生方式，更符合其面向对象的模型设计，避免了SQL式外键带来的冗余复杂度。

内容的提问来源于stack exchange，提问作者ccsv