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?
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.
Will a paid user have extra functionality in all accounts? Then the flag belongs in users.
Will any user have extra functionality in a paid account? Then the flag belongs in accounts.
Will a paid user have extra functionality only in paid accounts? Then the flag belongs in users_accounts.
If every account has only one owner, then you should put a user id representing the owner in the accounts table.
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 Usersand 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.
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.
Related
I have three entities in our environment, Account, User and Company. Right now I have tables for account, account_user, account_company, company and user. It seemed fine initially but now that I think about it, it seems like it could be simplified with the joining tables.
Every Account (portfolio) has 1 or more Companies and 1 or more User managing it
User Joe Doe logs in to view Account Joe's Accounts with company(s) Joe's Company &&/|| Joe's Wife's Company
How would it be in Logical Design (designing database tables and relationships)?
Hope I described this clearly
Thank you
This kind of schema might be of help to you.
Table Company :
Company ID NAME DESCRIPTION ETC
Table Account:
Account ID NAME DESCRIPTION ETC, Associated Company ID(foreign key)
Table User:
User Details
Table User_Permissions:
Users allowed on accounts
If you need one account to be part of multiple companies(which should not be the case) then you can make a bridge table for the account and companies too like for user permissions.
I'm developing an e-commerce site and I wanted to get this community's thoughts on a database structure for groups, users, and their memberships.
THE GOAL: Determine a user's group membership(s) and access privilege at login. A user could be a seller on this site, an admin, a site support, or ANYTHING. Must be scalable.
INITIAL THOUGHT: Three separate tables: users, groups, and memberships. At a successful login, search the membership table for the user's ID and get group ID's from that same row in the membership table. From there, another query to get group information from the groups table (like name of group, description, etc). Store the memberships in the user's session and call it a day.
THE CONCERN: At log in, I don't want to unnecessarily perform additional queries. The above "initial thought" consists of 3 separate queries at login.
THE QUESTIONS:
Is this the right approach?
Any better design solution(s)?
Better to break admins into their own table, or toss 'em into the same groups table?
The database design is reasonable. As a user can belong to multiple groups and can have multiple memberships, two additional tables USER_GROUP and USER_MEMBERSHIPto hold the relations between users and groups and between users and memberships will be necessary.
For an ecommerce site that allows both Guest checkouts and registered user checkouts, how will you handle the 2 different customer groups?
Do you store both groups in the same table customers which has a foreign key customer_group_id pointing to another table customer_groups? In this case, will you worry about duplicate guest checkouts "polluting" the customers table?
How will the information captured for the 2 customer groups be different? I am thinking the difference is that the guest checkout customers will not have a password thats it.
I store customer information directly in the order rather than rely on the information in the customer record. That does a couple things:
I don't have to have a guest user in the customer database
If my customer information changes, or if a customer wants to ship one item to one place, and another item to another place the information about the order will still be correct.
I view order information as historical data. It should not change because something else in your database changes. For example if I order something from you, and at some later time I move and update my billing and shipping information, you should still know that the previous order was billed and shipped to the previous address. If you rely on the relationship between the customer and the order to retain bill to and ship to information, Once I move and update my profile, you think you shipped to my new address. You may not see that as an issue, but it will be.
You can still get the current information from the customer record to populate the fields on the order if the customer has an account. For a guest, he has to type it every time.
The common entity is a Checkout. The guest checkout would be a null FK link on the checkout entity to a registerd user entity.
I am designing a database for a Yii project, the scenario is a user will be ONLY one of the following type: employee, company and business owner person (i.e. the owners who manage companies and employees - super admin - I broke the many to many relationship that's why I call the table "business_owner_person"). Below is how I designed my database in MySQL:
USER
id,
username,
password,
active
COMPANY
id,
name,
contact_no,
contact_name,
address...
user_id (FK)
EMPLOYEE
id,
first_name,
surname,
address,
email...
company_id (FK)
user_id (FK)
BUSINESS_OWNER_PERSON
id,
name,
email,
position...
user_id (FK)
I am just wondering if there is a better/efficient way to design this scenario so that Yii won't have the problem to fetch the correct additional informations for user.
It's difficult to make suggestions without knowing a little more about the business, but it seems like you have too much redundant information.
Splitting out the user is good, since any of these types of people can be a user. I would probably put the common information, name, email into the user field, maybe even the address and position.
Then what it looks like you want is that a user can have one or more roles, where the role controls their level of access. This could be as simple, to start out with as a role_id columns in the DB table, or it could be a separate table, user_id, role_id.
Now, all that being said, it's difficult to make suggestions without more information. Do you need to isolate users by company? Will there be a lot of companies? How many business owners are you looking at having?
My question is about modeling a particular situation:
In my model I have tables: User, Offices and Partners.
The system has different user profiles: users of Office (counselors, principals, assistants), users for Partners (Institutions,..), admin users.
What is the best way to model the relationship between office users and partner users if:
- The users are unique (two users should have the same login - should be in only 1 table)
- An office user is associated to only one office
- A partner user is associated only with a partner.
It should be a table for office users and one for partners users?
A many to many relationships in this case would not work, right?
Thanks for your help.
You have not provided enough definition re Partners and Offices, so those parts of the model are not yet complete, but I think the main question you are asking is answered in this ▶Data Model◀. As I understand it:
User (login, UserName is unique, and you do not want that to be unclear)
Users are exclusively (that is the X in the half-circle) Office/Partner/Administrator
that requires a Supertype-Subtype structure. The cardinality is 1::0-1
Users belong to (?) an Office or a Partner, exclusively.
That may be OfficeType or OfficeTitle.
If you define that last item a bit more, I can finish the model.
Readers who are unfamiliar with the Standard for Modelling Relational Databases may find the ▶IDEF1X Notation◀ helpful.
Assuming this model will never change I would add a field to the users to determine where they belong. You could put an enum named user_type with possible values of 'office', 'partner', or 'admin'.. And then you could put in columns of office_id, and partner_id so you could join the tables as needed.
I think the best route would be to go with an account group structure, where you use an association table to determine who's in what group...
group
id | name
group_assoc
group_id | account_id