Reputation: 11422
I had a question about the best way to handle this type of data.
In my system, I will have many users and many accounts... users are able to belong to many accounts, and accounts will have many users. I'm guessing the best way to accomplish this is with three tables
users
accounts
& users_accounts
my question is, when someone signs up for a paid account... where should I store the flag that distinguishes between regular users of an account and account holders? Should there be an owner flag in the users_accounts table?
Upvotes: 1
Views: 121
Reputation: 86
Add a paid
flag to user_account
.
Example Attributes:
user (id, name, street ...)
account (id, name ...)
user_account (user_id, account_id, paid)
You can tell by the paid
column if the user is a premium account member or not.
Upvotes: 0
Reputation: 4313
Can I assume that one account cannot have more than one user (1-to-many relation)? In that case, two tables would be sufficient:
users
accounts
Where accounts
contain a reference to a user id. A separate relationship table would be superfluous when there is no many-to-many relation.
Then the question arises: can a user have both paid and unpaid accounts? If so, the flag belongs in accounts
. Otherwise, it belongs in users
.
Taking your clarification into account, your three tables design is appropriate. The answer to your question then completely depends on how you want paid accounts to work.
users
.accounts
.users_accounts
.If every account has only one owner, then you should put a user id representing the owner in the accounts
table.
Upvotes: 1
Reputation: 41
Users
table will have only the user related data... name, surname, etc...
accounts
will have the info of the account... type and any other data...
The key is that users_accounts
is a relation table between Users
and accounts
so it will have any linking data from the Users
to the accounts
and THERE you should put the flag because is there when you set the relations.
Upvotes: 0