オブジェクトモデルの設計

Question

このタイプのデータを処理する最良の方法について質問がありました。

私のシステムでは、多くのユーザーと多くのアカウントを持ちます...ユーザーは多くのアカウントに所属でき、アカウントには多くのユーザーが所属します。私はこれを実現する最良の方法は、3つのテーブル

ユーザー

が

& users_accounts

私の質問は、誰かが有料アカウントにサインアップするとき、あるアカウントである推測しています...アカウントの通常のユーザーとアカウント所有者を区別するフラグはどこに保存する必要がありますか？ users_accountsテーブルに所有者フラグがありますか？

Answer 1

1つのアカウントに複数のユーザー（1対多の関係）を割り当てることはできません。その場合、二つのテーブルは十分であろう。

• users
• accountsユーザIDへの参照を含むaccounts

。多対多の関係がない場合は、別の関係表が不要になります。

次に、問題が発生します。ユーザーは有料アカウントと未払いアカウントの両方を持つことができますか？その場合、フラグはaccountsに属します。それ以外の場合はusersに属します。

---

あなたの明確化を考慮すると、3つのテーブルデザインが適切です。あなたの質問に対する答えは、支払ったアカウントをどのように働かせるかによってまったく異なります。

• 有料ユーザーは、すべてのアカウントで追加機能を利用できますか？その後、フラグはusersに属します。
• ユーザーは有料アカウントで追加機能を利用できますか？その後、フラグはaccountsに属します。
• 有料ユーザーは有料アカウントでのみ追加機能を利用できますか？その後、フラグはusers_accountsに属します。

---

すべてのアカウントは一つだけオーナーを持っている場合は、accountsテーブルに所有者を表すユーザIDを入れる必要があります。テーブルにはユーザーのみに関連するデータ...名前、姓、などがあります

Answer 2

Users ... accountsアカウント...タイプおよびその他のデータの情報を持っています...

キーusers_accountsはUsersとaccountsの間のリレーションテーブルなので、Usersからaccountsへのリンクデータがあります。リレーションを設定すると、そこにフラグが入るはずです。

Answer 3

paidフラグをuser_accountに追加します。

例属性：

• user (id, name, street ...)
• account (id, name ...)
• user_account (user_id, account_id, paid)

ユーザーは、プレミアムアカウントのメンバーであるかどうかあなたがpaid列で伝えることができます。