sql - How to introduce new concept into database table structure for 0..1 instances? -

i have issue i've encountered new requirements , don't know how best structure database tables. situation follows:

i have employees stored in employees table. due increase in production, company has had hire many temporary employees. of these employees, both permanent , temporary employees, have enter data erp system. so, essentially, employees entering "orders" orders table having field named "enteredby". in ideal world, have both of these 2 types of employees stored in employees table.

due company's different systems in place , groups within company not talking each other, temporary employees become permanent employees, need way report on of orders "new" permanent employee has done while "temporary employees" , technically "merge" data temporary employee worked on new permanent employee record.

not temporary employees become permanent employees. orders have have "employee" attached it, i.e. foreign key holding employee's unique identifier.

i stuck on how incorporate concept of "temporary employee" data model , still upholding data integrity orders. suggestions?

current db table structure:

employee

• employeeid (pk)
• firstname
• lastname
• ... other attributes

order

• orderid (pk)
• employeeid (fk)
• ... other attributes

update 1: when trying convey problem in database table design when decided seek advice experts. in analysis of solution via oop, design of [tempemployee] [employee], wasn't able wrap brain on how convey table design , crud operations. fyi, [employee] has many fields while [tempemployee] has subset of fields, of fields existing in employee.

(i'm assuming possible load temporary employees employees)

inheritance common scenario in modelling - in case, seems can extend existing employee structure, can model temporary employees follows:

temporaryemployee  - employeeid (pk , fk employee)  - startdate  - enddate  - other temp employee fields here 

because temporaryemployee employee, shares employee primary key, , referential integrity can enforced via making temporaryemployee.employeeid foreign key employee.employeeid.

the integrity of orders unaffected, since existing employees-orders ri unchanged. benefit of extending rather changing haven't changed of underlying model, regression issues caused change erp system should avoided (although testing still essential).

edit, clarification:

existing erp system tables:

create table employee (    employeeid int identity(1,1) not null primary key,    employeetypeid ? -- e.g. might able repurpose identity temporary employees?    -- other employee fields here ... not of these relevant temporaryemployee );  create table orders (    orderid int identity(1,1) not null primary key,    employeeid int not null foreign key references employee(employeeid)    -- etc. ); 

now extend employee table, without changing above schema @ all:

create table tempemployee (    employeeid int not null primary key,    -- other extended fields here per above     constraint fk_tempemployee_employee references employee(employeeid) );