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.
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 am fairly new to MS Access and looking for a solution regarding a form I am trying to build. The form should be used to show different user entries and to create or modify users.
The problem I am blocking is for a combo box and a many-to-many relationship.
I have several tables which combined provide me the information I use to build the form.
My first table Users provides me information about *first name, last name etc. *
A second table Servers includes the list of different country servers a user can have access to.
Since an user can have access to different servers/countries and a country/server can have different users I am confronted with a many-to-many relationship. Therefore I created a junction table which includes the userID as FK (from the User table) and the ID as FK (of the country/server from the Servers table).
What I am trying to achieve now but where I am blocking is:
to have a combobox which lists all available servers/countries
mark the entries which are linked to the user record which is shown
e.g.
Servers: Belgium, Germany, Netherlands, Sweden, UK
User: John Doe => access to Germany & UK
list/combobox should show all countries but select only the ones John doe has access to (when record John Doe is selected)
Is there any way to achieve this and what needs to be done ?
I am also open for any other solution if this cannot be done via a combobox.
Thanks for the help.
I have a task in which I have to represent a M-N Relationship between a Users table and a Courses one. The goal is to allow only some Users (with a level of privilege) to see some Courses details(other tables related). The things get complicated because a user can have multiple privilege levels on different courses. For example - attending Course1 will give him privilege 1, watching Course2 will give him privilege 2 and so on. I am thinking to have a table users_courses which will store the relationship between a user and a course and also the privilege level (e.g. for columns: UserID | CourseID | Privilege).
The question is, can I create this join table including Privilege field ?
Is there another simpler approach ?
You can use RBAC pattern for that purpose. The picture below shows an example using users, permisions, and applicationes. In your case you would be using users, privileges and courses. You can also use roles for a better privileges handling.
I have an application which handles the creation of different shop entities.
The process:
1. User registers to the website
2. User creates a shop (with various attributes)
What I have so far for database tables is:
[USER]
user_id
[USER_TO_SHOP]
user_id
shop_id
[SHOP]
shop_id
The above design covers the need for 1 user to have many shop entities under their account.
What I want to achieve now, is to have shop entities which are standalone but also have shop entities which are a part of group of shops
Chain of Shops example:
McDonalds Address X Chicago
McDonalds Address X New York
McDonalds Address X Boston
How should I proceed with my database design in order to support chain of shops but also standalone ones? Best practices are really appreciated!
*by standalone I mean a shop entity that does not belong to a chain
Off the top of my head I'd have a locations table and rename shop to company so single companies go into that table but can have multiple locations. Then users are associated with a company location.
There are many ways to achieve what you want, so, answers will be subjective since we don't really have the whole picture.
From what you're saying, a shop can belong to between 0 and 1 chains? If so, I would simply add one extra table and add a foreign key to the shop table:
[CHAIN]
chain_id
chain_name
[SHOP]
shop_id
chain_id
Well, for chains, you could have something like this, just like you have for users:
[CHAIN]
chain_id
[CHAIN_TO_SHOP]
chain_id
shop_id
Not sure what you mean by a standalone shop though - if you mean a shop that isn't owned by a user or a chain, could be something like this:
[STANDALONE_SHOP]
shop_id
But I would question the need for such a table, since a standalone shop could be assumed by an absence of an entry in CHAIN_TO_SHOP or USER_TO_SHOP
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