ここに偽の会社、血液銀行があります。中心的なアイデアは、献血者のみが献血できるが、システムにログインできないということです。ただし、会社を表す「登録ユーザー」(user表の行) は、システムにログインして、会社が寄付した血液の量を確認できます。寄付者は企業とつながっている必要があります。まれに、「登録ユーザー」も献血を行うことができます。
- ユーザー = 「登録ユーザー」。ログインできます。
- 寄付者＝ログインできません。
- Admin = サイト管理者。ログインできます。
- 血液銀行の従業員 = 自明です。ログインできます。
将来的には、「登録ユーザー」のタイプを区別するなど、他のタイプのユーザーが存在する可能性があります。たぶん、多分。
解決策 1
- 別のドナー テーブル。
長所:
- 特にテーブルが大きくなった場合、ドナーを見つけるためのクエリが高速になります
短所：
- 寄付者が突然ログインしたくなった場合はどうすればよいですか? テーブルに重複するエントリを作成し
userますか? - 「登録ユーザー」が寄付したい場合は？テーブルに重複するエントリを作成し
donorますか?
解決策 2
ACL role/user_roleテーブルを使用してドナー (およびその他のユーザー タイプ) を定義する
長所:
- 後で「登録ユーザー」としてログインしたいドナーを簡単に処理できます
- 後から寄付者になりたい「登録ユーザー」の扱いも簡単
- また、任意のユーザーを管理者に昇格させるのも簡単です
短所：
- 「password」、「throttled」など、ドナーが必要としないフィールドがあるため、 余分な NULL が存在します。
解決策 3
追加のテーブルを作成する点を除いて、ソリューション 2 と同じuser_typeです。これは、ログインとユーザー アカウント タイプの詳細を制御するために ACL システムを再利用することを避けるために行われます。
解決策 4
ユーザーを集約します。
これは、集約ユーザーを使用するという user1759572 の提案に基づいています。正確にモデル化できていない可能性があります。
どのオプションを使用しますか? 4番目.. 5番目のオプション.. もっと良いものはありますか?
どんな返信でも大歓迎です。これは、私がここ数日検討してきたデザインの最終的な部分を突き止めるのに役立ちます. 引数。ありがとうございます！