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
Related
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
I'm new to MySQL and databases, and this question is more about best practices than exact code.
If I want to create a database that let's users register an "account" so they are then able to access and track the value of virtual goods in a video game, including selecting items from a list and marking them (thus requiring the choices to be associated with their account), Is it better to store the users choices in the same table that holds their username/account-info? Or should the information be stored in a separate table with a reference to the associated account?
Or should I create a table for each user, instead of having one for registration/account info, and another for data, etc.?
Does the best practice for this vary with the expected number of users and/or amount of data?
Is there a way to set it up that allows for handling growth from 2 or 3 users to hundreds?
The answer is to create one table for accounts, one table with choices that are referenced to that account with some type of token.
There's no reason to create a new table for each user. You should have one table, and differentiate between the users using the data in the table (e.g., the userid, the username, etc).
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.
Im thinking about what is the better way to design a database with the following statements:
There are 3 kinds of users (3 differents roles).
They have some common fields, however they have differents fields too.
Solution A:
All user in the same table (some users will have empty fieds depending of their role).
Solution B:
A main table where i will add users and their role. In addition i will create 3 extra tables where i will record with extra fields (depending of the table) and each record will have an id related with the user in the main table.
Solution C: A main table with basic user info, and a second table with the metadata user info where each record means a field of a user. That it's similar than WordPress
Yours is a case of Specialization/Generalization. Since you said User (1, 2, 3) share common properties, it is best to have a General entity - User with all the common attributes.
Then you can Specialize to 3 different types and have the specific attributes to each type.
So, option B is what I think is best solution for your problem.
Option A will cause too many null values and option C is overly complicated.
That depends :-)
Will you ever treat the users the same? E.g. at login time: Will someone just login with a username and this can be any of the three user types? Then you need a user table with a username and a unique index on it. This is solution A or B. I'd prefer B over A, so you can decide which of the fields are nullable for the specific role.
Or will you never deal with a user with an unknown role (such as: a person logs in with a role plus a username, so it suffices to have three different tables each with their own usernames)? This would be three special user tables and no common user table.
Option C would be something easy to implement in order to give users additional attributes, but can become a hassle. Especially when there are obligatory fields and fields that link to other tables (such as a job number that is meant to be the key in the jobs table, but you cannot use a foreign key then). I usually don't take this route, if it is avoidable.
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.