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.
Related
I'm trying to create a clone of a very popular application called Discord which allows people to communicate over voice, video, and text.
Discord allows every user to create their own servers and invite people to them. In order to allow users to create servers, I first created 2 tables - users and servers
Users table:
id, username, password
And
Servers table:
id, name, image, userId
So the relationship between these 2 tables is that a user can create and have many servers and a server belongs to a user. So far, so good.
Once a server is created, users can join the server as members of that server. A user can join as many servers as he wants and a server can have many members. I achieved this by creating a server_users junction table and a many-to-many relationship between users and servers:
Server_Users table:
id, userId, serverId
This works fine, however, I'm not sure if the logic behind the many-to-many relationship between users and servers is sound. To me it seems like I'm applying 2 relationships between users and servers and I don't know if this is correct. Maybe I need more tables to make the relationships clear?
User has many servers and a server belongs to a user ( Because a user is the owner/creator of a server, and the server belongs to only 1 user - his creator )
Server has many users and users have many servers ( As in every server can have many members and every member can be a part of many servers )
I think it's good design, almost a textbook example. The goal is that the tables are in normal form, which is the case here.
An alternate design also with three tables, if you would like to "merge" the two relationships, is to also use Server_Users to store the user who owns the server, marked as such with a boolean column. However, I think it is more efficient how you did it with a foreign key (userId), as you will only need one join for the 1-to-N relationship.
I would also add that the design of the table is not only motivated by getting this right "theoretically", but also by your use case. Picking a design depends on the kinds of queries that you will run against the database. If you list all users on a server including the owner, but never the owner alone, then the alternate approach may be faster.
Another aspect is integrity constraints: do you require that the owner of the server is also a member of that server, or is it fully independent? This also influences the design.
An alternative in the context of large quantities of data that do not get updated often, is to denormalize everything, by nesting the users (replicated) inside the server tuples.
I think your approaches are good.
As discribed before it's depending on your use cases or future functions.
In my opinion you have this possibilities:
Possibility 1
user
id
username
password
server
id
name
image
userId
adminId (references user id of admin/owner/creator)
user_server
id
userId
serverId
Possibility 2
user
id
username
password
server
id
name
image
userId
user_server
id
userId
serverId
admin (null if not an admin and true if an admin/owner/creator)
Possibility 3
user
id
username
password
server
id
name
image
userId
roleId (1=normal user, 2=admin,3=moderator)
user_server
id
userId
serverId
role
id
rolename
With possibility 1 you are limited to one owner of a server.
With possibility 2 you could add a "admin flag" to each user wich is allowed to manage the server. (like in chat groups of a messanger where exists multiple group admins)
With possibility 3 you could add a system to manage the rights of the corresponding users.
I am trying to develop a new website for event management system.
I want everyone to sign up as a simple user only and then if they chose to run event user can then create an Organisation and create events.
Every club will have lots of staff members who should then be able to log in and make changes into the event. Like accounting,event set up and entries, Refunds etc.
So I have created few roles like following
clubOwner :- All permission
eventManager :- Tier 1
treasurer :- Tier 2
Now how should I structure staff roles and permission table so that if in future creator of the club leaves that organisation he/she can easily nominate someone else clubOwner.
It is also the case that one eventManager handles events for different clubs or they can also run events under own Organisation name.
So far I have come up with following structure
clubs
=========
id | clubName | clubOwner
club_staff
id | clubId | accountId | roleId
club_roles
id | name
club_role_permission
id | roleId | permissionId
club_role_permission_details
id| name |
I am not sure if this will solve both of my problem of clubOwner easily nominating other user and same user with different roles in different clubs.
Any suggestion will be appreciated.
Thank you
Though this topic is subjective to many developers, I believe you are in the right track.
Permissions - normally corresponds to smallest unit of actions like View Club Staff, Add Club Staff, Remove Club Staff and so on. Normal club staff can view other staff within their club, but cannot add or remove club members.
Roles - are group of Permissions that are related to each other. ClubManagerRole for example must have all the permissions related to managing the club, while ClubStaffRole can only view members for example.
Users - are your users, that's all.
UserRoles - a junction table which has many-to-many relationship between Users and Roles. In other words, a user can have many roles, and a certain role can be assigned to many users. Just like how there are many Club Managers but maybe some of them can also be Other Managers.
Clubs - are your clubs.
ClubUsers (or staff) - are the users of a club. If a certain user is allowed to be a staff of one club only, one-to-many will be a fit choice. Otherwise, you can go with a junction table again for many-to-many relationship which will allow for users being assigned to many clubs.
The nomenclatures again, are also subjective. You can search for Database practices/normalization to get a basic a idea on how one can come up with a good schema.
I'm trying to figure out the best way to design these tables for a website I'm making for a school club. I want to set it up so each user can have multiple emails, phone numbers, and addresses tied to their account. To do this I tried to tie all these things to a contacts table and store the contacts id in the users table as a foreign key. The contacts id is also a foreign key in the emails, phone numbers, and addresses table. Is this a feasible way of relating these tables or should I just cut out the middle man (contacts table) and store the user id in the emails, phone numbers, and addresses tables?
Just in case my description of the relationships weren't enough, here is an ERD for the tables:
Sorry for such a "noob" question, it's been a while since I had to build a database with more complexity than 2 tables. Any general tips for database design are very much welcomed as well.
All you need to do is remove the Contacts table and store the user_id in the tables on the right, rather than contact_id.
Remove contact_id from Users as well.
I have dealt with this very question in the past. We did it wrong and we were sorry.
The determining factors should be these:
Will you have any other category of person that isn't a user, for whom you need to store contact information?
Will those kinds of persons somehow be "fungible" with users?
If you answer both these questions "yes," keep your contact table. Otherwise get rid of it.
The mistake made by a team I worked on was our answer to the second question. We had medical patients and doctors/nurses/etc as our categories of people. We stored their contact information together. But we shouldn't have done that because patients' contact information is very sensitive and confidential, but health care provider information is much less so. We were always wishing we didn't have the two kinds of data in just one set of tables after the system became successful.
Unless you can convince yourself you need your contact table, get rid of it, I say!
Yes I would cut out the midle man:
Although I was tempted to go the 'contact_type' route, I have found that there are usually validations and different data types which become more complicated when the contact is generic. For instance a table that has address fields is not the same as a phone number and having both presents more complexity and less readability.
This model focuses on simplicity, e.g. a user has many emails and an email belongs ot a user.
According to me you can design DB accordingly
Table 1 : Users
UserID //PK
Name
Table 2 : Contacts
ContactID //PK
UserID //FK to Users
ContactTypeID // FK to ContactType
Value
Table 3 : ContactType
ContactTypeID //PK
ContactTypeName
Description
Table 1 is pretty clear stores user information
Table 3 holds information about contacttype i.e email, home phone, mobile, home address, shipping address, etc
Table 2 holds information about user, contact type and its value
like cinatacttypeid corresponds to mobile than value is , etc.
I have a question and now I'm learning little by little on my own what is database.
good results that I have a computer retail store and the store is in Personal Service (Manager, Administrator, vendor and Support) and Clients (natural and legal), all these must have a user name and password you will have privileges access (User, Service Personnel).
As the design would make it?. what I want is to manage access privileges and so avoid some table inheritance, but not if it should apply in my case or only with Access, because from a table called PERSON alleged and another table called SALES, if for example, a person is a seller and one other staff person is a user who will buy anything at the table SALE I want to save the data of seller personnel and ladders, and if you only have one table called pERSON Would that double relationship?, should be two of the FK ID PERSON?
In a good model, you have to think in infinite-1, infinite-infinite, 1-1 relations.
So, a good model must be:
every table for a kind of object (persons, sales, etc)
every group of kind (administrator, sellerman, buyer, etc)
if you have infinite tables, you must create a table for relations.
e.g. for infinite-infinite (1 person can has 1 or more kind):
PERSONS
- Person_ID
- Firstname
- Lastname
- Address
WORK
-Work_ID
-Kind (Administrator, seller, etc)
REL_PERS_WORK
-Rel_Id
-Person_ID (from PERSONS table)
-Work_ID (from WORK table)
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.