laravel 雄辩的关系 3 模型

Posted 2023-03-15

【中文标题】laravel 雄辩的关系 3 模型

【英文标题】：laravel eloquent relation 3 models

【发布时间】：2018-02-19 04:19:10

【问题描述】：

我有一个 Laravel 5.4 项目，其中有一些模型：Client、Owner、Employee、Bank strong>（实际上是银行账户，但我选择银行是为了方便命名约定，以便与外键建立关系）。

现在有一些事实：

每个客户可以拥有多个银行（银行账户）。 每个所有者可以拥有多个银行（银行账户）。 每个员工可以拥有多个银行（银行账户）。 每个银行（账户）只能有一个 [客户或所有者或员工]

建立表格和关系的最佳方式是什么。 我想到了以下几点：

表格：

客户：id、bank_id、其他字段... 所有者：id、bank_id、其他字段... 员工：id、bank_id、其他字段... 银行：id、client_id、owner_id、employee_id、其他字段...

模型关系

Client hasMany Banks and Bank belogsTo Client [按照 Laravel 的指示完成] Owner hasMany Banks and Bank belogsTo Owner Employee hasMany Banks and Bank belogsTo Employee

现在在构建银行刀片视图表单时（创建/更新） 我应该有一个下拉菜单，例如belongs_to 字段包含 Client、Owner、Employee 作为选项 - 然后，我可以过滤掉三个表之一来选择 holder的银行帐户来分配它。

缺点：

对于 3 个表之一，每个银行一次只有一个有效的外键，例如client_id = 36，另外两个的值总是 0，例如owner_id = 0 & employee_id = 0)

这是建立关系的最佳方式还是有其他更好的方式？如果可能，请提供银行的刀片视图表。

【参考方案1】：

看起来很适合polymorphic relationship。

您的表结构将类似于：

客户：id、其他字段... 所有者：id、其他字段... 员工：id、其他字段... 银行：id、bankable_id、bankable_type、其他字段...

与您提议的结构的主要区别在于我们没有在客户、所有者或雇员表中指定银行（因为它们可以有多个）。相反，我们使用 bankable_id 和 bankable_type 指定银行所属的用户类型。

然后在您的三个用户模型中的每一个中；客户、业主和员工，你有以下几点（最好把它放在一个特质中）：

public function banks()

    return $this->morphMany('App\Bank', 'bankable');

在您的银行模型中，您可以：

public function bankable()

    return $this->morphTo();

这将返回拥有银行的用户（客户、所有者或员工模型）。

【讨论】：

是的，它是执行多态关系的完美方式，但由于无法解析 Client/Owner/Employee 类路径，因此无法按原样工作并返回空集合。要解决这个问题：*存储模型的完整路径，例如db 中 bankable_type 字段中的 App\Client 或 * 在类声明上方的 Bank 模型中映射关系：使用 Illuminate\Database\Eloquent\Relations\Relation；关系::morphMap([ 'client' => 'App\Client', 'owner' => 'App\Owner', 'employee' => 'App\Employee', ]); * 我更喜欢第二种解决方案，因为它将 db 与 laravel 代码分离。

【参考方案2】：

这种关系适合Polymorphic Relation。

您可以将您的银行帐户应用到类似这样的其他关系之一

class BankAccount extends Model 

    public function accountOwner()
    
        return $this->morphTo();
    


class Client extends Model

    public function bankAccount()
    
        return $this->morphMany('BankAccount', 'bankAccount');
    

请注意，我使用了 BankAccount 这个名称，因为我真的建议使用一个特别提及它所代表的名称的名称。将来，您或其他一些开发人员可能会对“银行”实际上意味着“银行账户”感到困惑。而且您还应该考虑如果您决定将银行添加到您的模型中，您会怎么做，因此每个账户都属于一个“银行”。

多态关系的明显缺点是数据库表上不能有物理外键。

【讨论】：

是的，这是将其作为多态关系的完美方式，但没有按原样工作，经过调查，我发现以下内容：* 关系返回空集合，因为它找不到客户端/所有者/员工类路径并对此进行排序：