I have a user table setup where a user can either belong to a Supplier or a Customer organization, which can have multiple users.
My original idea for the User table was to have a customerID and a SupplierID in the user table, out of which one will be filled, based on the organization the user belongs to. This does however not feel right, but I feel like maintaining two linking tables for this is overkill as well.
What would be the best practice in this case? I do not expect there to be any more organizations added in the future, but I do want to futureproof the application, by allowing multiple users to belong to the same organization.
you can design user or organization table with a column organization type which has value: supplier/customer and a column for organizationId
Related
In a relational database, what would be the best way to implement a relationship where several users each have several interactions with each other?
Method 1: I have an interactions table where two of the attributes are userID1, userID2 and the type of the interaction. Problem: Each time a user wants to access its interactions I will have to look into ALL interactions from ALL users ion the table interactions and find, specifically, every instance of interaction with that user. I would guess this is time-consuming and heavy processing.
Method 2: On the other hand, for the user table I can create a field which links to an interactions table that links with a table of interactions from that user - so each user has an interactions table from himself to other users. Problem: To me, it seems faster to search for interactions because every time the user accesses its notifications I just need his ID. However, I would have to create a table for each user which doesn't seem good design to me and can come with many problems.
What is the best (most efficient and best practice) design pattern to use in this case?
3rd normal form would suggest
Table: Users, PK UserID
Table: Interactions PK InteractionID
Table UserInteractions PK UsrIntID, FK UserID, FK InteractionID
Each Interaction can have 2...N users
Each User can have 0..N Interactions.
Get the User (Interactor), look them up in the the UserInteractions to get a list of their interactions and the associated Users. Lookup up Users (Interactees) to get user data for other participants
I am trying to design a database schema for a project using mysql as the database. and i am stuck on the authorization part, the business rules are as follows:
a role can have many permissions, and a permission and can be inserted in many roles
a user can have many roles, and one role can be assigned to many users
now this is the part that can't get it right, Every user can be in many "groups" but in each he can be assigned only to one role (by groups i mean group of people and not group of roles)
the following picture is what i came up with till now, what should be amended?
Based on your question and answer to my comment, here is the model I came up with:
This meets your requirements. The main difference with your model is how the groups are setup.
Group has a 1:1 relation with Role, which can be null (i.e. a group can exist even it no role is associated to it).
In each Group, you have a foreign key to the Role table.
If you need to know the roles a users has: individual roles through User_has_Role + role attached to each group the user is a member of (through Group_has_User).
There can be a table for each group which contains user and effective role(as user in one group can have only one role). There is also one implementation specific flaw, if user can be in multiple groups and in one group he can have only one role, so there must be some provision to decide effective group for the user which is going to decide effective role for user.
If users relationship with the group is only factor that decides the role user can have, then there is no point of having direct relationship between user and role.
I have a users table for registered users. These registered users can add contacts that have registered (Registered users) and also contacts that have not registered (That can register in future).
What is the best database structure?
Should I create two User tables (Registered and unregistered) having
ID as primary key and using the Email as a unique identifier.
Should I store all contacts (registered and unregistered in the same
table #Users Table) having in mind that not-existing users/emails
can be added to the table making it to have alot of users that may
never exist.
I manage a website since 6 years and I have all the users in the same table with a column named "profile", with any problem at all. Is very useful to have all in the same table.
You could have a boolean column: registered and non registered.
No need to create two tables you can create separate column for user_status it can be registered or not and email can be a unique column and for non registered users it will be null (violating normalization principals ) but it will work for you
To stay nth normalized and flexible in your design to use Contact information for purposes beyond even your description I would go with.
Contacts Table -- everyone with shared contact details
Users Table - specific to users and details in regards to user accounts (e.g. encrypted/hash password and email)
Now if you only want a 1 to 1 relationship between User & Contact simply include a foreign key to Contacts Table on the Users Table.
If you want to allow for a one to many, or many to many use a 3rd table to store relationships between users and contacts. I would see this as rare and it is definitely very difficult to manage, but I have learned from my own guest data environment that email addresses are never really unique to an individual. Families share! Husband wife, kids, etc. Also depending on what you are selling/doing the same person may want 2 accounts 1 for business and 1 for personal, Or 1 she doesn't care about her husband seeing and 1 she does. Plus if you ever want to allow for groups to use the same account you might want to capture all of the contact information.
I am designing a product that is mainly to be used by small organizations. The idea is for every member of the organization to have their own accounts (known as subaccounts). At the same time, there needs to be data that can be accessed by anyone with that organization. I am trying to decide between two courses of action.
Separate Table for Organizations
In this design, there would be a organizations table and a users table. The users would be connected to organizations via foreign key, and the shared data would use the foreign id of the organization.
User Conglomerate
Here an additional field in the users table would point to another row in the table (the parent) that represents the primary account for the organization and is linked to all the shared data.
Which approach would be superior in this situation?
Both approaches seem reasonable and workable, but I would lean towards having a separate table for organizations as ultimately the idea of an 'organization' is different to that of an 'user'. You may need to have different attributes for an organization than you would a user (e.g. you may need to have more than one 'superuser' for an organization at some stage), and so having this data in a separate table would make it (a) easier to code against (b) more extensible and future-proof (c) more efficient and normalized in storage.
I've a table of USERS in mysql that is in relation m:n with a CITY table.
User are 3 types identified by a field TYPE: regular, admin, super.
The regular user could be linked at maximum with 1 city.
The admin user could be linked at max just with 1 city.
The Super user is linked with all cities.
Is correct to store all 3 types of user in just one table and having n:m that for most user is just 1:m and just the SUPER USER is a pure n:m. is that the correct approach?
Personally, I don't think you need separate relational table (even if it is mostly good idea for future improvements, should you decide that user needs to connect to more than 1 city).
What I would do instead, is create city_id column in users table, and fill it accordingly. I am saying this because of the SUPER USERSs, as you call them. If you create separate relational table, it will have (number of super users) * (number of cities) entries, and since super user can see all cities, you would need to add (number of cities) rows to the table, each time you create a new user. Also, each time you create a new city, you would need to add (number of super users) rows to the relational table.
Instead, as I said, I would just use city_id in the users table, and if the user if super user then he sees all cities, and if not, only the city from city_id column.
This is just my personal preference.
Let me know what you think.