I have a user_id colunm in the user table. Next I have a brand_id in the brand table. The usecase is each has their own page: The user has a profile and the brand has a brand page. (NOTE: Thgere are more relationships like this. A company has a company page, city has city page, etc). So when users upload photos I need to reference it to the owner. Owner can be brand, user, city, organization, etc.
For user's it is straightforward, photo_id belongs to user_id where user_id is a FK to user table. But to add the brand_id as the owner of the photo, do i require a seperate colunm or can it be done in the user_id colunm itself if i rename it as owner_id which will reference (userid or brand id)?
2 columns, hands down. (One of the two must of course always be null)
With a single column you have a number of issues:
No DB-level referential constraints (= foreign key)
Risk of ID clashes between brand and user table
Confusing
You could create one mapping table for each, such as user_photos and brand_photos.
That way you have full referential integrity from user_photos to user and brand_photos to brands. This also have a possitive impact on performance for queries that filters on user/brand photos.
Related
How to properly implement mysql table relation such that a user can create multiple business and each of those business can have multiple users. thanks
Basically going to be two (possibly 3 tables):
Business Table:
business_id int (this will be the primary key)
business_name
whatever extra fields that relate to the business
User Table:
user_id whatever type (this will be the primary key)
user_name
whatever extra fields that relate to the business
The relational part you can implement in one of two ways:
add the business id to the user table. So user table will have an additional field business_id and will relate back to one of the rows in the business table. This implies a user can only relate to 1 business.
If you want a user to be able to relate to one or more businesses then you need a separate table:
Business_User Table:
business_id int
user_id (whatever type you picked)
I am designing a database for my app. In which I want to do mapping between multiple tables. Now situation is like There is one user table. User can have generate multiple orders. So I was thinking if I can put json obejct of order_id in a column in order table. Or I can create a user_id column in order table & repeat user_id for same user. So which is a better way of doing it?
PS: What is the standard way of doing it?
You should just have user_id in your order table, then make queries like
select * from orders where user_id = *some_user_id*
A user can place multiple orders which in turn can have multiple line items. Each line item can have n quantity of a specific product. So when product comes in picture, then it becomes many to many relationship between user and product because a user can place order for many products and a product can be ordered by many users. So my suggestion is -
Create a User table with UserID
Create a PurchaseOrder table with OrderID, UserID and LineItemID
Create a LineItem table with OrderID, ProductID and LineItemID
Create a SKU table with ProductID
A user can place multiple orders.
Based on this you should maintain three different tables as given below:
User (user_id,...)
Order (order_id,...)
UserOrder (user_id,order_id,...)
Only the primary keys in the above tables are focused
Storing comma separated list or json object will worsen the design. And this is strongly discouraged.
EDIT:
As #NevilleK suggested, the above design is typically used for many-to-many relationships. For one-to-many relationship you can create a foreign key constraint in orders table where user_id should refer to the user_id in the User table.
But still you can adopt the above design for one-to-many relationship since many-to-many qualifies for one-to-many too.
The best way is to have different table for your
User table - which hosts the user information
Transaction table - which will have order_id against each user_id.
Transaction table will carry all the transaction details with user_id. If you create a JSON object, how will you map the USER to the transaction. So at the time of retrieving the json information you will have to map it to the user table anyway. I suggest you the use the above said method, which will help you maintain and scale your application much easily.
I have a web application which allows users to join multiple groups.
I have a 'users' table which stores details about the users (id, email, password, etc.) and a 'groups' table which stores details about the available groups (id, name, owner of group).
I have been researching the best way to store group memberships (i.e. which users are in which group, bearing in mind they can be members of multiple) - however I am still not sure what the most efficient solution would be.
Would you recommend I:-
Create a second table called 'group_memberships' and store the user's ID along with the corresponding group ID?
Store an array alongside the group particulars in the 'groups' table with the user IDs of its members?
Approach this task a different way?
The DBMS I am using is phpMyAdmin.
I would advise you to go with option 1; where you have a Mapping Table for linking Users & Groups.
The Users Table will have PK on User_ID.
The Groups table will have PK on Group_ID.
The Mapping table will have User_ID(FK) and Group_ID(FK).
Now you should have PK on these two columns together.
This will ensure you don't have duplicate entries.
What you're describing is called a many-to-many relationship in database terms. A user can belong to multiple groups, and groups have more than one user (or else they wouldn't be "groups"!).
Your first idea, the group_memberships table, is the accepted best way to model this relationship. Although you'll want to name it users_groups or something similar to reflect the fact it relates or associates those two tables. At its most basic, this association table needs three columns:
ID (primary key)
user_id (foreign key)
group_id (foreign key)
By JOINing to this table ON either user_id or group_id, you can find the related records from either side of the relationship. And you can do it right from a SQL query, without any additional code like you'd need if you stored an array.
I would definitely go with option 1 - creating the junction table 'group_memberships' - I have used this approach many times without problems. Don't forget to add an Index on the new table 'group_memberships' for columns: 'groupID' and 'userID'.
Option 2 is not scalable for a large amount of data, especially if groups have a lot of users.
UPDATE:
For info on Indexes, here is a good (and short) blog: https://blog.viaduct.io/mysql-indexes-primer/.
The first option is a right choice. Actually it is a materialized view for both user table and group table.
Just think materialized view as a extra table or a redundant data structure that denormalizes the user properties and group properties together for quick search.
Since if we do not have the view, when we query a group id to list all its users, we have to filter millions of users to check if he/she is in the certain group. It is a performance nightmare!
Mysql has tools to build this view very efficiently. You may build secondary index on this view columns for quick search, say, group id, group name, user id, user name or something else you hope to search with.
good luck :-)
I'm creating a website and users can add friends. I want them to be able to see their personal friends on a page.
For exemple:
John add user Tim and Bill.
When John goes on his friends list page, I want him to be able to see that he has Tim and Bill. How do I do that? Is that even possible? Do I need more than one table? If so, does every user has to have his own friendsList table?
Yes this is possible, you do this by querying the information from the database, the answer for if you need multiple tables etc all depends on your current table structure but at the very least you need to have some way of referencing that a Person 'John' has friends, wether thats just a 'friendID' in the same 'Person' table, or another means of doing so. then it is just a matter of querying the data correctly to return what you want and bind to the websites fields :D
One way of defining the structure is the following:
Person
PersonId
Name
<other person fields>
Relationship
RelationshipId
Name --> allow to define multiple relation types like Friendship, Follows etc.
Relationship
RelationshipId
Person1Id --> FK to Person
Person2Id --> FK to Person
RelationshipTypeId --> FK Relationship
Basically, you use an n:n between Persons (anyone can have any number of friends) and also allow for other types of relationships.
Assuming you already have a table of users, one approach would be to create a "friends" table which relates users to other users.
CREATE TABLE friends (
`user_id` INT NOT NULL,
`friend_id` INT NOT NULL
);
Both user_id and friend_id would have foreign key constraints on your existing users table (so that you guarantee an id must exist in your user table in order for it to exist in the friends table as either a user_id or friend_id).
You can then link your user table on users.id = friends.friend_id to get the friend's info.
Here is a SQL Fiddle Demo showing how this works.
You should consider using an ON DELETE CASCADE constraint on the friends table, so that if a user is deleted from the user table, the associated records in the friends table are also deleted.
I am modeling a database that will hold data relating sales from a shop. I have two different kind of users which have distinct properties.
In my normalization process I created a User1 Table and a User2 Table.
The problem I have is tracking sales. For example if I want to track sales say for a particular kind of user for a product and know the users buying trends for that product, I would have to create two tables, Bread1 and Bread2 for the two types of users.
I came up with a solution but I don't know the performance implications on the long run or if its the best solution at all. The solution is having a unified table User which have the ID's of both users.
If there is any other better solution, I would appreciate it.
Thanks.
Better to have just one table for Users and one for Products and so on. You can easily categorize your users or products by making an another table for grouping them.
UserTypes(UserTypeId PK, ...)
Users(UserId PK, UserTypeId FK, ...)
Also for properties you mentioned for users or even for products, You can have a list of properties in a table and assign them by a third table to users.
Properties(PropertyId PK, Name)
UsersProperties(UserPropertyId PK, UserId FK, PropertyId FK, Value)