简体   繁体   English

如何(重新)组织这些数据 - Lumen/Laravel

[英]How to (re)organize this data - Lumen/Laravel

So far, my Lumen based Backend-API fetches the following results from my MariaDB:到目前为止,我的基于 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"
  }
}]

What you're seeing is the fetch from 3 Tables, one Coretable and two extensiontables.您看到的是从 3 个表中获取的数据,一个 Coretable 和两个扩展表。 The coretable contains the "Internal_Key" and it is referenced by the extensiontables via its id, which I declared hidden in the model and therefore its currently not being displayed in the fetchresults. coretable 包含“Internal_Key”,它通过它的 id 被扩展表引用,我声明它隐藏在模型中,因此它当前没有显示在 fetchresults 中。 The line of code executing this fetch looks like this:执行此提取的代码行如下所示:

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

The $permittedTables is an array of tablenames, so basically any number and combination of extensiontables can be fetched alongside the referenced records from the coretable. $permittedTables是一个表名数组,因此基本上任何数量和组合的扩展表都可以与核心表中的引用记录一起提取。

The data shall ultimately be inserted into a list-like view.数据最终应插入到类似列表的视图中。 Here, for each "Internal_key" a row shall be created into which all the data associated with that key will be inserted.此处,对于每个“Internal_key”,应创建一行,其中将插入与该键关联的所有数据。

I'm perfectly fine with the current structure of the data, as I can loop through it however I want and thereby extract the data accordingly to the needs of the list.我对数据的当前结构非常满意,因为我可以随意遍历它,从而根据列表的需要提取数据。 However, I would like to know if there is any way to (re)organize it differently.但是,我想知道是否有任何方法可以(重新)以不同的方式组织它。 If I wanted to put each set of data from the extensiontables on the same "arraylevel" as its respective Internal_key, how should I do this?如果我想将扩展表中的每组数据放在与其各自 Internal_key 相同的“arraylevel”上,我应该怎么做? Should I change the way I fetch the data, or should rearrange the data after the fetch?我应该改变获取数据的方式,还是应该在获取后重新排列数据? And in both cases: Whats the easiest, most reliable way to do it?在这两种情况下:最简单、最可靠的方法是什么?

EDIT: Some more info on the structure of my DB.编辑:有关我的数据库结构的更多信息。 Coretable has an ID as primary Key which is referenced in the extensiontables via the "coretable_id" FK. Coretable 有一个 ID 作为主键,它通过“coretable_id”FK 在扩展表中引用。 Here is the schema of my foreign keys for my DB:这是我的数据库的外键架构:

+------------------------------------+-----------------------------+--------------------------------------+--------------------------+------------------------+
| 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                     |
+------------------------------------+-----------------------------+--------------------------------------+--------------------------+------------------------+

First of all: we don't have informations on the coretable and extensiontables models, so we don't know if you've implemented Polymorphic Relationships , which would possibly fit your scope perfectly.首先:我们没有关于 coretable 和 extensiontables 模型的信息,所以我们不知道你是否已经实现了多态关系,这可能完全适合你的范围。

That said, a possible reorganization would be to flatten the tree to an array of objects, with也就是说,可能的重组是将树展平为一组对象,其中

  • A property referencing the internal key引用内部键的属性
  • Other properties storing their type extensiontable source in the name, eg "desc_itc" : "EXTENSION_iTC_1"在名称中存储其类型扩展表源的其他属性,例如"desc_itc" : "EXTENSION_iTC_1"

That would leave you with something like this:那会给你留下这样的东西:

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

EDIT: You mentioned in your comment that there's a one to one relationship with every foreign key only present in an extensiontable, and referencing coretable.id with the key coretable_id .编辑:您在您的评论中提到,有一个人跟每一个外键只存在于extensiontable,并引用一个关系coretable.id用钥匙coretable_id

Another way to organize this data would be to add two columns to coretable , extendable_type e extendable_id and implement a one to one polymorphic relationship : storing the model name in the extendable_type column will let you invoke all extensions by simply accessing the extendable property of your Eloquent model, eg组织这次数据的另一种方法是将两列添加到coretableextendable_type Ë extendable_id并实施一对一多态的关系:在存储的型号名extendable_type通过仅仅访问柱会让你调用所有扩展extendable你的雄辩的财产模型,例如

$extendable = $core->extendable;

In order to achieve this, you'd only have to define the following method in the coretable model:为了实现这一点,您只需要在coretable模型中定义以下方法:

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

And this to each extensiontable_* model:这对于每个extensiontable_*模型:

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

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM