あなたのアプローチは素晴らしく、正規化されているように見えます。
私が見逃していることの 1 つは、非許可テーブル、つまりアクションを許可しないテーブルです。
Active Directoryにはこれがあり、これにより、オブジェクトへのアクセス許可をすばやくブロックできます。
これにより、次を除くすべてのアカウントへのアクセスを許可できます。.....
逆の場合は、HR データを除外して各オブジェクトへのアクセスを許可する必要があります。
最初の方法では 2 つのオブジェクトにアクセス許可を設定します (親に 1 つのアクセス許可、子に 1 つの却下)、2 番目の方法では数十のアクセス許可に実行できます。
個人的には、permissions表を更新して除外も含めます。
これにより、グループとユーザーの両方に除外を適用できます。
ブラックホール テーブルを使用して新しいアクセス
許可の
追加を簡素化する 新しいアクセス許可の追加を簡素化するために、新しいブラックホール テーブルを作成できます。
これは何も保存しませんが、代わりに挿入を行うトリガーを起動します。このようにして、DB が正規化されているという事実を挿入コードから隠すことができます。
CREATE TABLE bh_permission (
user_or_group_id unsiged integer not null,
isuser ENUM('user','group') not null default 'user',
permission_description varchar(255) not null,
allow_or_not ENUM('allow','forbid') not null default 'allow'
) ENGINE = BLACKHOLE;
これで、group または user_id のいずれかを指定してテーブルに挿入できます
INSERT INTO bh_permission VALUES ('123','group','p_HR_files_2011','forbid');
そして、技術的な詳細を処理するトリガーを用意します。
DELIMITER $$
CREATE TRIGGER ai_bh_permission_each AFTER INSERT ON bh_permission FOR EACH ROW
BEGIN
DECLARE Mypermission_id INTEGER;
//like is always case-insensitive, `=` is not.
SELECT p.id INTO Mypermission_id FROM permissions p
WHERE name LIKE NEW.permission_description LIMIT 1;
IF isuser = 'user' THEN
INSERT IGNORE INTO user_permission (user_id, permission_id, allow_or_not)
VALUES (NEW.user_or_group_id, Mypermission_id, NEW.allow_or_not);
ELSE
INSERT IGNORE INTO group_permission (group_id, permission_id, allow_or_not)
VALUES (NEW.user_or_group_id, Mypermission_id, NEW.allow_or_not);
END IF;
END $$
DELIMITER ;