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.
Related
So I want to make a webapp that needs to store the following.
"Users"
some "Events"
and some "Customers"
each "Event" has a "User" which is represented by a userId column.
But each "Event" can have multiple customers, to be able to store all this info,
I thought it's better to have a new table "Customers_In_Events" that has 3 columns:
id, -- Not sure if that's needed
e_id -- Event ID
c_id -- Customer ID
I have 2 questions...
Is there some better way to do this?
If I decide to go with the way I mentioned (an extra table), Would the "id" column be needed?
I am using MySQL by the way.
You can use a bridge model to represent your data, which is also normalized.
every event can have multiple customers
every customer can have multiple events
so the tabkes would look like
Events events_coustmers cutonuers
e_id(PK) e_id(fk) c_id(Pk)
e_name c_id(fk) c_name
PK(e_id,c_id)
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 have a users table and at the moment a table for storing the users information. The users have a role of buyer or as seller. where the seller has some additional fields that the buyer doesn't have.
Now im wondering what will be a good approach to use. create a table for the users information where i refer to the users id, or two separated tables. One table for the buyers information referring to the user id and one for the sellers information with the exta fields referring to the user id. Where you fill the table according to the users role.
There will be millions of users inside this table so thats something to keep in mind here.
Any help will be appreciated.
Generally you put all the information both types of users share (and that fits on one records of course) in the User table. Then if you need more information by type create a table for that type. If you only need more information right now for sellers, then create a sellers table. If buyers also have specialized fields, then create a buyers table. If however, you do not at this time have any specialized fields to add for the buyers table, then you may not need one at this time. It can be added later if your data model changes.
If this table (these tables) is going to be in a one-to-one relationship with the User table, then make sure to create the Userid as both the FK (to users)and the PK of the child table to maintain data integrity.
You should use two tables, one for users and the other for associates
users
+id
user_name
...
associates
+id
user_id
assoc_type //buyer or seller
...
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)
I am new to database designing. In my case I have to generate lot many keys per user per product. So, I have two options -
Create one table with product_id and key for all the users, or
Create a separate table for each user
In the former case I will have a single table but querying might take more time as all the entries are in the same table for all the users.
In the later case queries might return the result faster but more tables and if users cross 100 or more than it means lot of tables.
Definitely do not create a table for each user. if you create a single table for all users you can use relational database design and add specific information pertaining to each user like address or employee information and use the primary key from the users table as a foreign key. and there will not be any noticeable lag. And maintenance will be whole lot easier
if you want to build relation between your user and product then make table like below
user_product [table name]
id [Primary Key]
user_id [Reference key of user table]
product_id [Reference key of product table]
key
This is your table schema You must use.
if you generate each table then this will take more complex for database and relation management. So, just use above row base format.
if that helpful then let me know.
Thanks