ユーザーと組織が共有するフォルダーの設計：組織ビデオホルダーの最適な拡張
はじめに
前回の記事では、「フォルダー」から「オーガニゼーションビデオホルダー」への命名変更について提案しました。今回は、その設計を踏まえ、ユーザーと組織がどのようにフォルダーを作成・共有できるかについて深掘りしていきます。
この記事では、組織とユーザーがフォルダーを通じてビデオを管理する設計を考え、最適な方法を提示します。特に、フォルダーが中間テーブルとして機能しつつも、ユーザーがフォルダーを作成できるようにするための設計案について詳しく見ていきます。
現在の状況
前回の記事では、folders テーブルを organization_video_holders という名前に変更する提案を行いました。これにより、フォルダーが組織がビデオを管理するための中間テーブルであることを明確にしました。
しかし、次の問題が浮かび上がってきました。
・ユーザーがフォルダーを作成できない
・組織とユーザーの関係性が複雑になっている
・そこで、今回はこれらの問題に対応するために、以下の2つの設計案を提示します。
設計案1: 組織とユーザーのフォルダーを分離
この設計では、組織のフォルダーとユーザーのフォルダーを完全に分離します。具体的には、organization_video_holders テーブルに user_id を追加し、ユーザー専用のフォルダーも作成できるようにします。
テーブル設計
# migration to add user_id to organization_video_holders
class AddUserIdToOrganizationVideoHolders < ActiveRecord::Migration[6.0]
def change
add_reference :organization_video_holders, :user, foreign_key: true
end
end
この設計では、organization_id と user_id のどちらか一方に値が入ることで、フォルダーが「組織専用」か「ユーザー専用」かを区別します。これにより、シンプルな管理が可能となり、保守性が向上します。
メリット
・シンプルさ: フォルダーの所有者が明確で、組織とユーザーのフォルダーが完全に分離されるため、複雑なアクセス制御の必要がありません。
・保守が容易: 明確に所有者が定義されているため、データの操作や保守が簡単になります。
デメリット
・共有フォルダーが難しい: ユーザーと組織がフォルダーを共有できないため、共有フォルダーのニーズがある場合にはこの設計では不十分です。
設計案2: フォルダーの共有を可能にする
次に、組織とユーザーがフォルダーを共有できる設計を提案します。この場合、組織とユーザーが同じフォルダーにアクセスする可能性があるため、フォルダーのアクセス権を管理する中間テーブルを追加します。
テーブル設計
organization_video_holders テーブル
# migration to add user_id and organization_id to organization_video_holders
class AddUserIdAndOrganizationIdToOrganizationVideoHolders < ActiveRecord::Migration[6.0]
def change
add_reference :organization_video_holders, :user, foreign_key: true
add_reference :organization_video_holders, :organization, foreign_key: true
end
end
folder_accesses テーブル
# migration to create folder_accesses table
class CreateFolderAccesses < ActiveRecord::Migration[6.0]
def change
create_table :folder_accesses do |t|
t.references :organization_video_holder, foreign_key: true
t.references :user, foreign_key: true
t.references :organization, foreign_key: true
t.timestamps
end
end
end
この設計では、folder_accesses テーブルを使って、フォルダーへのアクセス権を管理します。これにより、組織とユーザーが同じフォルダーを共有でき、柔軟なアクセス管理が可能になります。
メリット
・柔軟な共有: 組織とユーザーが同じフォルダーを共有できるため、プロジェクトやチームでの協力が促進されます。
・詳細なアクセス管理: folder_accesses テーブルを使うことで、フォルダーごとに詳細なアクセス権限を設定できます。
デメリット
・複雑な管理: アクセス権を管理するためのロジックが増えるため、シンプルさを犠牲にすることになります。
おすすめの設計
プロジェクトの要件次第ではありますが、より柔軟な設計が求められる場合には「設計案2」をおすすめします。理由は次の通りです。
組織とユーザーが協力してビデオを管理するシナリオがある場合、共有フォルダーの設計が柔軟である方が適しています。
folder_accesses テーブルを使うことで、アクセス管理の柔軟性が高まり、将来的な拡張も容易です。
ただし、シンプルさを求める場合は、設計案1の方が実装や保守が簡単なので、プロジェクトの規模や要件に応じて判断すると良いでしょう。
結論
今回の記事では、ユーザーがフォルダーを作成する場合や、組織とユーザーがフォルダーを共有する設計について考察しました。
・設計案1: 組織とユーザーのフォルダーを分離し、シンプルな管理を実現
・設計案2: フォルダーを共有可能にし、柔軟なアクセス管理を提供
どちらの設計も一長一短がありますが、プロジェクトの要件に応じて、どちらを採用するかを検討してみてください。共有が必要でない場合はシンプルな設計案1が有効ですが、将来的な拡張性やチームでの協力を考慮するなら設計案2がベストです。