Click here to Skip to main content
15,846,976 members
Please Sign up or sign in to vote.
1.00/5 (3 votes)
See more:
SQL
create table employee(

emp_id       int,
insurance   varchar(20),
constraint employee_pk
primary key (emp_id),

);



create table selesperson(
target              varchar(20),
emp_id int
constraint salesperson_pk
primary key (emp_id)
foreign key references employee(emp_id),
);


I am a little bit confused concerning disjoint table
just to double check the meaning if I have employee as parent class and salesperson as subclass so it is supposed that primary key in employee is primary key and foreign key in table salesperson or not?

What I have tried:

I am a little bit confused concerning disjoint table
just to double check the meaning if I have employee as parent class and salesperson as subclass so it is supposed that primary key in employee is primary key and foreign key in table salesperson or not?

so please if anyone could explain to me how to join parent class with subclass
Posted
Updated 14-Dec-22 5:27am
v2
Comments
Richard Deeming 14-Dec-22 9:56am    
Another question about SQL, and once again you've forgotten to include any details of what the actual problem is.

And once again you've tagged your question as "CSS", which is completely irrelevant.
Member 15627495 14-Dec-22 10:24am    
'class' is about OOP , database design doesn't need it.
but it brings clear information about your aim.
// at this point, you can choose to have a field by 'auto increment' in your 'salesperson' table,
or using every time needed the emp_id ( from employee table ) .
the question : does the salesperson table need a primary key : answer is NO.
only a column (int):'emp_id' is needed as foreign key.
Member 15627495 14-Dec-22 10:25am    
the relation between 'employee' and 'salesperson' will be established by, for both tables, the 'emp_id' columns

1 solution

Why are you creating a separate table for salesperson at all? Since there is a one-to-one relationship between "being a salesperson" and "being an employee" all you are doing is complicating issues. Presumably, you will also have separate tables for "maintance", "software engineer", "cleaner", "CEO", and so forth. Which won't be confusing, at all.

And having "Target" and "Insurance" which are presumably numbers stored as a strings is just ... well, useless for all practical purposes.

Have an employee table: Add a "EmployeeType" table which contains each possible type of employee, and link that to the employee table so each employee has a valid type. The add a separate "SalesTarget" table which includes a date range, an employeeID, and and a target for the period.

To be honest from all your questions so far it looks like you are trying to get through an SQL course without learning much, or thinking about it at all - and that's a great way to fail a course since when it comes up on the final exam you won't have access to outside help ... I'd strongly suggest you rethink your homework strategy.
 
Share this answer
 
Comments
Richard Deeming 14-Dec-22 10:55am    
To be fair, "table per type" is one of Microsoft's Entity Framework mapping strategies for inheritance:
Inheritance - EF Core | Microsoft Learn[^]

But they do at least warn that: "In many cases, TPT shows inferior performance when compared to TPH." ("TPH" being essentially the strategy you've described here.)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900