title: User database design for marketplace-style app
body: <p>Need some best-practice wisdom as I'm new to database architecture. This is for a marketplace type app. The main issue I'd like advice on is handling users. </p>
  
  <p>What I'd like to achieve is buyer and seller accounts share login/signup functionality and some characteristics, but seller accounts have the ability to sell, receive payments, etc. Buyers can send requests, sellers can complete them. Basically a seller can do everything a buyer can do, but additionally view and fulfill requests, and sell.</p>
  
  <p>I'd go with simple roles, except sellers have more complex relationships than buyers in terms of products and payment info. Also sellers need to be able to be publicly listed, and have public profiles. I'm not sure that having 1 big table with both users types would be ideal for this.</p>
  
  <p>My current idea is to use polymorphic associations between a base User table and a seller table (potentially a buyer specific table as well):</p>
  
  <h2>User (buyer)</h2>
  
  <ul>
  <li>name</li>
  <li>email</li>
  <li>encrypted_password</li>
  <li>(other authentication fields)</li>
  <li>location</li>
  <li>occupation</li>
  <li>meta_id</li>
  <li>meta_type</li>
  </ul>
  
  <h2>Seller</h2>
  
  <ul>
  <li>name</li>
  <li>location</li>
  <li>occupation</li>
  <li>etc</li>
  </ul>
  
  <h2>requests (belongs to buyer and seller)</h2>
  
  <ul>
  <li>type</li>
  <li>description</li>
  <li>complete</li>
  <li>buyer_id</li>
  <li>seller_id</li>
  </ul>
  
  <h2>products (belongs to seller)</h2>
  
  <ul>
  <li>description</li>
  <li>category_id</li>
  <li>seller_id</li>
  </ul>
  
  <p>As you can see, a big issue is that fact that buyers and sellers have duplicate data. The reason for this is because when I'm displaying sellers I don't want to have to perform multi-table queries, but maybe that's not an issue? Another option would be to have the User base table and then buyer and seller tables, but they'd still contain duplicate info.</p>
  
  <p>Open to all possibilities.. What's the best way to go?</p>