Separate Users Across 2 Tables? - mysql

Question

I'm building a Ruby on Rails application, I'm separating two sets of users:
Buyers
Sellers
Currently someone built the database with both under a Users table with:
t.string "user_type", default: "buyer", null: false
There are some additional data I will need to hold for Sellers and there is also a few features/pages I want Sellers to have access to, but not Buyers.
For example I want to hold bank details so I can pay Sellers what we are paid by Buyers (we hold payments for a few days to ensure safe transaction). So the additional data may be:
Account Number
Sort Code
We do not need to store this data for Buyers since they use Stripe for payment.
Do we include the data on the current Users table? or do we create a new Sellers table that is linked to the Users table?

Answer 1

You can use one table and have the differences in the models. As users, they will share many common features, e.g. authentication during sign_in, change password, etc.
class User < ActiveRecord::Base
...
end
class Buyer < User
def buyer_specific_method_one
...
end
end
class Seller < User
def seller_specific_method_one
...
end
end
And add a string field named 'type' to the user table. See Single Table Inheritance.

Answer 2

There is a number of options you can use. Not necessarily one, some combinations are possible:
Factor out differences (bank details?) into separate models with one-one relationships with User
You can make them one-many later if you need to, one seller may provide info for multiple banks
You do not restrict your users from being both buyer and a seller simultaneously (if you want)
If these details are not needed on every single request, the performance penalty is not too big
Single Table Inheritance
Alter the string column user_type to be just type, then make two more models without a table (--no-migration), inheriting not from ActiveRecord::Base, but from User, so they inherit its table for persistence
Your users table will need to have all the columns from all subclasses
Any User subclasses (like Buyer) will be defined as a User with certain type ("Buyer")
Serialize attributes that you'll be processing on app level only, not in the database
You'll need to create a text-type column for each collection of serialized attributes that you want
You'll only be restricted by the format of serializer, not database columns and types, it allows you to store arbitrary data there
You can define a custom serializer that outputs custom objects (maybe even models?)
Be extra careful not to allow users to arbitrarily edit collections
Make sure you only need serialized data from already loaded objects, contrary is a design flaw