下の画像に示すように、3つの関連するテーブルがあります。
全員がUserテーブルとUserRoleにエントリを持っています。一部のユーザーはサブスクライバーです。
サブスクライバーテーブルを制約して、ロールがIsSusbcriberであるユーザーのみを含めることができ、UserRoleをユーザーレベルで保持できるようにします。出来ますか?
テーブル間の現在の関係を失礼します。それらは、必然的に必要なものではなく、現時点でそこにあるものを表しています。
下の画像に示すように、3つの関連するテーブルがあります。
全員がUserテーブルとUserRoleにエントリを持っています。一部のユーザーはサブスクライバーです。
サブスクライバーテーブルを制約して、ロールがIsSusbcriberであるユーザーのみを含めることができ、UserRoleをユーザーレベルで保持できるようにします。出来ますか?
テーブル間の現在の関係を失礼します。それらは、必然的に必要なものではなく、現時点でそこにあるものを表しています。
列を削除して、以前に列を設定したロールを正確に含むテーブルをIsSubscriber
追加できると思います。UserSubscriberRoles
IsSubscriber
CREATE UserSubscriberRoles
( UserRoleId PRIMARY KEY
, FOREIGN KEY (UserRoleId)
REFERENCES UserRoles (UserRoleId)
) ;
次に、Subscribers
テーブル内のFKを次のように変更します。
FOREIGN KEY (UserId, UserRoleId)
REFERENCES User (UserId, UserRoleId)
FOREIGN KEY (UserRoleId)
REFERENCES UserSubscriberRoles (UserRoleId)
出来ますか?
理論的には、そうです。SQLアサーションを使用できます。例については、このStackOverflowの回答を参照してください。
ただし、実際には、主要なDBMSはSQLアサーションをサポートしておらず、説明する内容を外部キー制約として実装することはできないため、この制約を評価し、満たされない場合は例外を発生させるトリガーを作成するしかないと思います。。
テーブルにRoleIdがない場合にこれを制限する唯一の方法は、トリガー(通常、トリガーは設計上の選択としては不適切です)、または基準に合わないユーザーをサブスクライバーから定期的に削除するSQLエージェントジョブを使用することです。
サブスクライバーのRoleIDを使用すると、特定の値に制限するチェック制約を追加できます。
これは、別の設計やアプリケーションコードで実際に実施する方が適切です。