私が取り組んでいるプロジェクトがあり、どちらが「より良い」テーブル関係スキーマになるかわかりません。
問題の領域の範囲は次のとおりです。
ユーザーがドキュメントをアップロードする (所有者/作成者になる)
ユーザーは他のユーザーとドキュメントを共有できます (共有権限の設定)
ドキュメントへのアクセス権を持つすべてのユーザーがドキュメントをチェックアウトできます (排他ロック)
私の元のスキーマは次のようになります。
利点は次のとおりです。
1 人のユーザーのみが作成者になることができます。(正式)
権利テーブルには「共有権」のみが含まれます (読み取り、書き込み)
ユーザーは、自分が「所有」しているファイル (authorid) と共有ファイル (sharedfiles テーブル) を簡単に区別できます。（これは弱い利点です、私は知っています）
いろいろ考えた後、これはより良いスキーマかもしれないと思いました:
利点は次のとおりです。
すべてのドキュメントの関連付けは 1 つの場所 (UserFiles) にあります。
1 つのドキュメントの複数の作成者/所有者を許可する将来の機能
権利テーブルには、読み取り、書き込み、および所有者が含まれるようになりました。ドキュメントがユーザーによってアップロードされるとすぐに、新しいドキュメントへの自動関連付けが行われ、ユーザーに「所有者」権限が与えられます。
これにより、最終的なスキーマにたどり着きました。
利点は次のとおりです。
- ユーザー ファイルの関連付けが削除され (共有が削除され)、そのユーザーがファイルをロックしている (チェックアウトされた) 場合、その排他ロックは自動的に削除されます。
この最後のモデルの唯一の問題は、各部門に「特別な」ユーザーを追加して、ユーザーが部門全体でドキュメントを共有できるようにすることです。したがって、共有の関連付けをcheckoutIDに関連付けるかどうかはわかりません（それが理にかなっている場合）。ユーザー ファイルのクエリは、「userfiles.userid = me.userid || (userfiles.id == SpecialDepID && me.depid == SpecialDepID) のすべてのファイルを選択する」のようになります (主要な疑似コード)。
データベース スキーマを作成してから長い時間が経ちましたが、この 1 つの設計上の決定に頭を悩ませています。どのデザインが「より良い」ものになるのか、本当に悩んでいます。より良いとは、より良いデザイン原則、以前の経験に基づいたより良い決定、デザインの「成長」を容易にすることなどを意味します。あなたの考えを教えてください!
最終的解決
Michael Madsen の助けを借りて、最終的なソリューションは次のようになります。
関係が削除されたときにロックを削除する必要があるかどうかを決定する削除のトリガーが UserFiles にあります。