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
);
A user is a user, which is different than a person.
A user is a role played by a person. A recruiter is also a role played by a person.
create table party(
id serial primary key,
name text not null
);
create table role_type(
id char(1) primary key,
name text not null unique
);
insert into role_type values
('u', 'user'),
('r', 'recruiter');
/* use Table Inheritance to add role-specific details. */
create table party_role(
party_id integer not null references party(id),
role_type char(1) not null references role_type(id),
...
primary key (party_id, role_type)
);
/* create a user: */
insert into party values
(1, 'Neil');
insert into party_role values
(1, 'u');
/* create someone that is both a recruiter and user: */
insert into party values
(2, 'Tristan');
insert into party_role values
(2, 'u'),
(2, 'r');
Best Answer
I've solved
2.
using sub-querys