誰かがこの多対多の関係を喜んで見てくれることを願っています。この例はLaravelプロジェクト用ですが、詳細はそれほど重要ではありません。
アクション
+----+------+--------+-------------+------+--------+------------+
| id | name | script | description | icon | custom | project_id |
+----+------+--------+-------------+------+--------+------------+
パイプライン（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パイプライン内のはすでに外部キーで設定されているため、現在の設定でこれらの事前定義されたアクション用に別のテーブルを単純に作成することはできません。
これまでのところpre-defined、user-definedアクションとユーザーが自分で作成したアクションの2つの概念を混ぜ合わせているように感じます。ただし、それらは同じパイプラインにあり、最終的には正しい順序で実行される必要があります。
これがどのように達成されるかについての考えはありますか？私はすべての提案を受け入れます。
編集
これを引き出した後、考えられる解決策は、別のピボットテーブルを追加して、テーブルからaction_projectを切り離す（削除する）ことができるようにすることです。Laravelでこれをきれいに保つ方法を考えています。project_idaction
action_project
+----+-----------+------------+
| id | action_id | project_id |
+----+-----------+------------+
問題を概念的に要約します。
必要なのは、両方のケースを包含するスーパークラスの「アクション」に対応する、カスタムアクションと標準アクションの一般化だけだと思います。これにより、次の表が表示されます。
actions(id, type, name, description)typeいずれかであることcustomかstandardcustom_actions(id, script, icon, custom, project_id)また、あなたはの属性追加できcustom_actionsにしactions、それらにのためのすべてのNULL持つ標準のアクションを。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加