Some Ideas In Database Design
As a general rule, and speaking very broadly, each "thing" in a database is represented by a row in a table. Each seller is a row in a table. Each purchaser is a row in a table. 

The simple, obvious, and arguably wrong approach is to have one table of sellers and another table of purchasers. The problem is that one real-world human can be both a seller and a purchaser. In other applications, one real-world person might be a doctor, a patient, and a hospital board member, all at the same time.

The problem with those two tables is that an update to, say, the email address for me in the sellers table might not be matched with a corresponding update to my email address in the purchasers table. And, in fact, that's almost certain to happen, because the row that corresponds to me in the sellers table probably won't have the same primary key as my row in the purchasers table.

For a working solution to the general case, see this SO answer. In your case, you're only talking about people. If you want to model people, sellers, and bidders, you're probably looking for something along these lines. This kind of structure allows one person to be both a seller and a bidder. (I think bidder is a better word than purchaser, if we're going along eBay lines.)

create table people (
  person_id integer primary key,
  full_name varchar(35) not null
);

create table sellers (
  person_id integer primary key references people (person_id),
  other_attributes_of_this_person_as_a_seller char(1) not null
);

create table bidders (
  person_id integer primary key references people (person_id),
  other_attributes_of_this_person_as_a_bidder char(1) not null
);