Как (пере) организовать эти данные - Lumen / Laravel - PullRequest
Новая
       147

Как (пере) организовать эти данные - Lumen / Laravel

3 голосов
/ 04 февраля 2020

Пока что мой Backend-API на основе Lumen получает следующие результаты из моего 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 и двух расширяемых таблиц. Базовая таблица содержит «Internal_Key», и на нее ссылаются расширяемые таблицы через ее идентификатор, который я объявил скрытым в модели, и поэтому в настоящее время он не отображается в результатах выборки. Строка кода, выполняющая эту выборку, выглядит следующим образом: 

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

$permittedTables - это массив имен таблиц, поэтому в принципе любое число и комбинацию расширенных таблиц могут быть выбраны вместе со ссылочными записями из основной таблицы.

Данные в конечном итоге должны быть вставлены в список, похожий на список. Здесь для каждого «Internal_key» должна быть создана строка, в которую будут вставлены все данные, связанные с этим ключом.

У меня все в порядке с текущей структурой данных, поскольку я могу oop просматривать их так, как я хочу, и тем самым извлекать данные в соответствии с потребностями списка. Тем не менее, я хотел бы знать, есть ли способ (ре) организовать его по-другому. Если бы я хотел поместить каждый набор данных из таблиц расширений в тот же «arraylevel», что и соответствующий ему Internal_key, как мне это сделать? Должен ли я изменить способ извлечения данных или переставить данные после извлечения? И в обоих случаях: Какой самый простой и надежный способ сделать это?

РЕДАКТИРОВАТЬ: Еще немного информации о структуре моей БД. Coretable имеет идентификатор в качестве первичного ключа, на который ссылаются в файлах расширений через FK «coretable_id». Вот схема моих внешних ключей для моей БД: 

+------------------------------------+-----------------------------+--------------------------------------+--------------------------+------------------------+
| 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 Ответ

2 голосов
/ 04 февраля 2020

Прежде всего: у нас нет информации о моделях coretable и extensiontables, поэтому мы не знаем, реализовали ли вы Polymorphi c 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 e extendable_id и реализовать отношение один к одному полиморф c : сохранение имени модели в столбце extendable_type позволит вам вызывать все расширенные с помощью простого доступа к свойству extendable вашей модели Eloquent, например, 

$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');
}
...