So I have been reading through the forum and there is good content around creating different types of users but I am still struggling with how to properly structure a buyer and seller from a database stand point. Currently when my “seller” signs up he/she is put into the user table and they have fields within that table that wouldn’t be relevant to my “buyers”. What in your opinion would be the best way to structure this? Thank you all in advance.
What I would do is have a type “ThingForSale” name is as you chose, and then it would have a field “Owner” which is of type User. You would need other fields to track if it is a draft item being created, or it is published to the public etc.
With a user logged in when they create a new ThingForSale, the Owner field would be set to value of Current User.
The user could then have a page (dashboard) where they can see all the items they have currently listed, either public or draft etc. and you would use a repeating group with the Do Search For Thing For Sale and the constraints would be Owner is Current User. The dashboard would only be visible to Logged in users and the system knows which user data to load by using the Current User
The ‘Seller’ is just another user, so they don’t need to be identified in any specific way, they just need to be able to list the ThingForSale where the status is Published or Public or however you chose to name the values.
You can then build off of this to include images, offers, messaging, viewcounts etc. etc.
Everything DaveA says is right, but I think it may not fully answer the question. Shadsanders89 might need seller fields like vendor rating that are irrelevant to buyers. In that case, you could keep everyone in the user table, but create another table of sellerInfo, which has a one-to-one link to the user table. When you create a new user and hit submit, a workflow would check the role field, and if it’s set to seller, it would create a sellerInfo record and populate it. You could use a constraint to hide the extra fields if role <> seller.
It’s slightly more complicated if the seller could also be a buyer. Instead of a role field, you’d need a seller field (yes/no) and a buyer field (yes/no). Depending on your app, you might need to know which role the user is playing at a given time, in order to know which fields to display.