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
...
Related
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 running for office and have created a web app for tracking my door knocks to voters at their homes. The database contains a table called voters that contains all the necessary information about voters in my community.
I'd like to add a new feature to track donors to my campaign. Not all of these donors live in the community and do not vote in the district where I'm running for office. I do not need to track the same kind of info for these individuals as I do for the voters so I'm going to place these individuals into a table called nonvoters.
Now, the individuals in my "voters" table can also make donations, and I want to track those as well.
To track the donations from both voters and nonvoters, I'd like to set up a new table called "donations." This table would contain the appropriate details about the donation.
But I'm uncertain as to what the best structure is for linking the donations table to the "voters" and "nonvoters" table. If I create a column called voter_id in the table to key it to the donors information, there's no way to know which table that ID refers to. So do I set up two columns, nonvoter_id and voter_id and insert the ID into the applicable column depending on whether the donor is a voter? This seems weird.
Or maybe I create a column in both the voters and nonvoters table called donor_id that I can use to link my data in the donations table. If I went this route, it seems like I'd have to do a some behind the scenes work to ensure the donor_id was unique and was keyed to the data inside the donations table.
Or maybe there are other approaches I'm not familiar with. Any guidance is appreciated.
I would use a single table for voters and non-voters, let's say persons. You can have a flag in the persons table that indicates if the person is a voter or you may even derive this from their address (if that's possible).
I would create a donations table and link each donation to a person (or persons) in the persons table using the id in the persons table. If a donation can be given by multiple people, then you will need a 3rd connection table with person id and donation id as 2 fields. These 2 fields would be the primary key for the connection table.
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 have a users database and a comments database on a website, and I want to give each user the ability to have a list of favorite comments, and I don't know exactly how to implement this.
Should I create a new table for each user containing the IDs of his/hers favorite comments or is there a better approach?
A common, normalized approach would be a many to many relationship.
The schema for such a table, at a minimum, would be:
user_id
comment_id
Where user_id and comment_id are foreign keys to the users and comments table, respectively.
I would use three tables :
The users table, containing every users, including their personal informations, etc ;
The comments table, containing every comments ;
The favorites table, containing the id of the row, the id of the user and the id of the comment.
I did not name each table well, you should think more about the tables' names (e.g: favorites is a bad name).