title: Database Design - sales from multiple sources
body: <p>We currently have a SQL database with a table that holds online sales for our company, which sells products using other websites (say, Amazon).  The table schema has been set up to hold specific sale data/attributes provided by the website our items are currently sold on (say, Site A). </p>
  
  <p>We are expanding sales to other websites that provide different attributes than Site A uses when an item is sold (e.g. Site A might provide a unique sales id number, and site B might not provide a unique sales id number, but also provide some other info that Site A doesn't provide that we still need to capture).</p>
  
  <p>The question is do I add a separate table for sales on each 'site' that we sell on, as the schema will be different, or try to combine all sales into one table, no matter the platform, leaving some columns null if it doesn't pertain to the particular platform? Or maybe a hybrid approach, separating only the attributes that aren't common among the two sites into separate tables, while a "master" sales table holds attributes that are shared (sale_price, sale_date, etc)?</p>
  
  <p>There are also other tables in play that hold internal information (product Ids, costs, etc), that are linked to the sales table via a unique identifier.  Whichever route I choose, I'd need come up with a unique identifier I could use across all tables (auto incremented sale_id, e.g.), and store that in a table for reference/joins.</p>
  
  <p>Any suggestions are welcomed!</p>