Схема базы данных многие-ко-многим со значениями по умолчанию - PullRequest
0 голосов
/ 11 сентября 2018

Я надеюсь, что кто-то захочет взглянуть на эти отношения многие ко многим .Этот пример для проекта Laravel, но особенности не должны иметь большого значения.

action

+----+------+--------+-------------+------+--------+------------+
| id | name | script | description | icon | custom | project_id |
+----+------+--------+-------------+------+--------+------------+

pipe (action_server это сводная таблица )

+----+-----------+-----------+-------+
| id | action_id | server_id | order |
+----+-----------+-----------+-------+

сервер

+----+------+------------+------------+
| id | name | ip_address | project_id |
+----+------+------------+------------+

Это многие ко многим отношение используется для сервера развертывания, действие является частью конвейера развертывания.

  • Действие может быть выполнено на нескольких серверах.
  • Пользователь может добавить действие с помощью пользовательского сценария.
  • Все действия для конвейера развертывания можно получить с помощью project_id

Эта концепция работаетвнутри Laravel и я мог бы просто получить свои действия, основываясь на данном project_id.В свою очередь, я мог получить действия сервера, необходимые для запуска развертывания, используя action->servers().

Мне нужен способ добавить действия по умолчанию.Вместо действий, всегда имеющих предоставленный пользователем сценарий , я хочу иметь возможность предоставлять действия с предопределенными сценариями, которые пользователь может выбрать и добавить в конвейер развертывания.

Эти предварительныеопределенные действия не могут быть помещены в таблицу action, потому что определенные там действия связаны с project_id.Они должны быть общими.

Я не могу просто создать другую таблицу для этих предопределенных действий в моей текущей установке, потому что action_id в моем конвейере уже настроен с внешним ключом.

Пока я чувствую, что я смешиваю 2 понятия, которые являются pre-defined действиями и user-defined действиями, которые пользователи создали сами.Они должны быть в одном конвейере и в конечном итоге работать в правильном порядке.

Есть какие-нибудь мысли о том, как этого можно достичь?Я открыт для всех предложений.

Редактировать

После вытягивания кажется возможным решением было бы добавить еще одну сводную таблицу в виде action_project, котораяпозволяет мне отделить (удалить) project_id от таблицы action.Мне интересно, как сохранить это в чистоте в Laravel, хотя.

action_project

+----+-----------+------------+
| id | action_id | project_id |
+----+-----------+------------+

1 Ответ

0 голосов
/ 12 сентября 2018

Обобщая вашу проблему концептуально:

  1. приложений ("проекты") связали пользовательских действий ,
  2. стандартные действия не определены для конкретного приложения
  3. серверы есть / хост приложения
  4. конвейеры определяют, какие "действия" выполнять на каком сервере в каком порядке

Я думаю, что вам нужно просто обобщение пользовательских действий и стандартных действий , соответствующих «действию» суперкласса, которое охватывает оба случая. Это приводит к следующим таблицам:

  1. actions(id, type, name, description) с type, равным custom или standard
  2. custom_actions(id, script, icon, custom, project_id)

Кроме того, вы можете добавить атрибуты custom_actions к actions и иметь их все NULL для стандартных действий .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...