2012-02-16 21 views
0

私は、ユーザーとユーザーの役割を持つスキーマ設計について考えていますが、どのような方法が良いか分かりません。ユーザーの役割DBスキーマの設計

1は3つのテーブル、ユーザ情報を有するもの、ロール情報を有するもの、および番目のユーザの役割の関係を有するものを作成するオプション。

users { 
    u_id, 
    etc 
} 

roles { 
    r_id, 
    r_name, 
    etc 
} 

user_roles { 
    u_idm 
    r_id 
} 

オプション2

、2つのテーブル、役割、役割情報、及び関連情報とユーザー情報と1、およびその他を作成します。

users { 
    u_id, 
    etc 
} 

roles { 
    r_id, 
    u_id, 
    r_name, 
    etc 
} 

オプション1はより堅牢ですが、追加の結合が必要です。オプション2は追加の主キーを必要としますが、1つの結合のみになります。ロール名を変更した場合は、オプションで更新するのに時間がかかりますが、頻繁に更新することはありません。

スケーラブルなソリューションの場合、それは良いでしょうか?私の行方不明の他の洞察?これはmysqlとpostgresqlの解決策です。

答えて

1

オプション1 1人のユーザーがそれぞれの役割を果たすことができる場合、どのような役割がありますか? 登録ユーザーが100人の場合は、「登録ユーザー」の定義が100個重複します。

「etc」が多いほど、データベースが大きくなります。

多くの重複があるとデータベースが遅くなり、最終的に結合が1つ少ない場合でも処理が大幅に遅くなります。

多くのロールベースのクエリーを実行し、オプション2のようなデータベースが必要な場合は、ビューを作成してデータベースキャッシュを作成することができますが、これは何か良いことはないと思います。

0

私はいくつかの変更と、最初のオプションとなるだろう:定義された

- each user can belong to ONLY ONE group 
- create a table defining privileges 
- each group has a list of privileges 

権限は、アプリケーションの様々なモジュールまたは特定の機能にマッピングすることができます。

解決策はシンプルで柔軟性があり、高速です。 特権とグループの両方のテーブルはかなり小さくなければならないので、追加のJOINはそのような重大な影響を与えません。また、認証されたユーザー権限はセッションに格納され、毎回読み込まれることはありません。 ソリューションは非常に柔軟で拡張が容易なため、長期的にはさらにメリットがあります。

たとえば、「構成」という新しいモジュールを作成し、「スーパー管理者」という新しいユーザーグループを作成して、すべての場所と「構成」にアクセスできるようにします。あなたは単にデータベースの変更を行います:グループ 'superadmin'を作成し、特権 '設定'を追加し、すべての特権を設定します。

+0

1つのグループがサイトの要件に対応していません。ユーザーは、ブランド、メンバー、ブランド管理者、クライアントなど、またはこれらの組み合わせのいずれかです。 –

関連する問題