如何（重新）组织这些数据 - Lumen/Laravel

Posted 2023-03-15

【中文标题】如何（重新）组织这些数据 - Lumen/Laravel

【英文标题】：How to (re)organize this data - Lumen/Laravel

【发布时间】：2020-05-20 01:42:31

【问题描述】：

到目前为止，我基于 Lumen 的后端 API 从我的 MariaDB 获取以下结果：

[
  "Internal_key": "TESTKEY_1",
  "extensiontable_itc": 
    "description": "EXTENSION_iTC_1"
  ,
  "extensiontable_sysops": 
    "description": "EXTENSION_SYSOPS_1"
  
, 
  "Internal_key": "TESTKEY_2",
  "extensiontable_itc": 
    "description": "EXTENSION_ITC_2"
  ,
  "extensiontable_sysops": 
    "description": "EXTENSION_SYSOPS_2"
  
, 
  "Internal_key": "TESTKEY_3",
  "extensiontable_itc": 
    "description": "EXTENSION_ITC_3"
  ,
  "extensiontable_sysops": 
    "description": "EXTENSION_SYSOPS_3"
  
, 
  "Internal_key": "TESTKEY_4",
  "extensiontable_itc": 
    "description": "EXTENSION_ITC_4"
  ,
  "extensiontable_sysops": 
    "description": "EXTENSION_SYSOPS_4"
  
, 
  "Internal_key": "TESTKEY_5",
  "extensiontable_itc": 
    "description": "EXTENSION_ITC_5"
  ,
  "extensiontable_sysops": 
    "description": "EXTENSION_SYSOPS_5"
  
]

您看到的是从 3 个表、一个 Coretable 和两个扩展表中提取的数据。 coretable 包含“Internal_Key”，扩展表通过它的 id 引用它，我在模型中声明它是隐藏的，因此它目前没有显示在 fetchresults 中。 执行此提取的代码行如下所示：

$join = coretable::with($permittedTables)->get();

$permittedTables 是一个表名数组，因此基本上可以从核心表中获取任何数量和组合的扩展表以及引用的记录。

数据最终将被插入到类似列表的视图中。在这里，对于每个“Internal_key”，应创建一个行，与该键关联的所有数据都将插入到该行中。

我对当前的数据结构非常满意，因为我可以根据需要循环遍历它，从而根据列表的需要提取数据。 但是，我想知道是否有任何方法可以（重新）以不同的方式组织它。 如果我想将扩展表中的每组数据与其各自的 Internal_key 放在相同的“arraylevel”上，我应该怎么做？ 我应该改变获取数据的方式，还是应该在获取后重新排列数据？ 在这两种情况下：最简单、最可靠的方法是什么？

编辑： 有关我的数据库结构的更多信息。 Coretable 有一个 ID 作为主键，通过“coretable_id”FK 在扩展表中引用。 这是我的数据库的外键架构：

+------------------------------------+-----------------------------+--------------------------------------+--------------------------+------------------------+
| TABLE_NAME                         | COLUMN_NAME                 | CONSTRAINT_NAME                      | REFERENCED_TABLE_NAME    | REFERENCED_COLUMN_NAME |
+------------------------------------+-----------------------------+--------------------------------------+--------------------------+------------------------+
| ad_usersxad_groups                 | Ad_user_id                  | fk_ad_groupxad_user                  | ad_users                 | id                     |
| ad_usersxad_groups                 | Ad_group_id                 | fk_ad_userxad_group                  | ad_groups                | id                     |
| extensiontables_registryxad_groups | ad_group_id                 | fk_ad_groupxextensiontables_registry | ad_groups                | id                     |
| extensiontables_registryxad_groups | extensiontables_registry_id | fk_extensiontables_registryxad_group | extensiontables_registry | id                     |
| extensiontable_itc                 | coretable_id                | fk_extensiontable_itc_coretable      | coretable                | id                     |
| extensiontable_sysops              | coretable_id                | fk_extensiontable_sysops_coretable   | coretable                | id                     |
| inaccessibletable                  | coretable_id                | fk_inaccessibletable_coretable       | coretable                | id                     |
+------------------------------------+-----------------------------+--------------------------------------+--------------------------+------------------------+

【参考方案1】：

首先：我们没有关于 coretable 和 extensiontables 模型的信息，所以我们不知道您是否实现了Polymorphic Relationships，这可能完全适合您的范围。

也就是说，可能的重组是将树扁平化为对象数组，使用

引用内部键的属性 在名称中存储其类型可扩展源的其他属性，例如"desc_itc" : "EXTENSION_iTC_1"

这会给你留下这样的东西：

[
  "Internal_key": "TESTKEY_1",
  "desc_itc": "EXTENSION_iTC_1",
  "desc_sysops": "EXTENSION_SYSOPS_1"
  
, ...
]

编辑：您在评论中提到，每个外键都存在一对一的关系，仅存在于扩展表中，并且使用键 coretable_id 引用 coretable.id。

组织这些数据的另一种方法是将两列添加到 coretable、extendable_type 和 extendable_id 并实现 one to one polymorphic relationship：将模型名称存储在 extendable_type 列中将允许您调用所有扩展只需访问 Eloquent 模型的 extendable 属性，例如

$extendable = $core->extendable;

为了实现这一点，您只需在 coretable 模型中定义以下方法：

/**
* Returns the matching extension data
*/
public function extendable() 
        return $this->morphTo();
    

这对每个extensiontable_* 模型：

/**
* Returns the matching core data
*/
public function coretable() 
  return $this->morphOne('App\coretable', 'extendable');

【讨论】：

我将在几秒钟内编辑更多关于我的数据库结构的信息！ :=)

编辑了关于coretable和扩展之间关系的信息:)

谢谢！哪些外键受 UNIQUE 约束？

基本上所有从扩展表到核心表的 FK。 Coretable 和 extensiontable 始终具有一对一的关系。因此，我将 UNIQUE 约束添加到外键。我希望这可以被视为一个不完全坏的做法？ xD

此外，coretable 和具有外键的表之间似乎没有关系。对吗？