Comment introduire un nouveau concept dans la structure de la table de database pour les instances 0..1?

J'ai rencontré un problème avec les nouvelles exigences et je ne sais pas comment structurer au mieux mes tables de database. La situation est essentiellement la suivante:

J'ai des employés stockés dans une table Employés. En raison d'une augmentation de la production, l'entreprise a dû embaucher de nombreux employés temporaires. Tous ces employés, qu'ils soient permanents ou temporaires, doivent saisir des données dans un système ERP. Donc, essentiellement, les employés entreront des "Commandes" avec la table Orders ayant un champ nommé "EnteredBy". Dans un monde idéal, ces deux types d'employés seraient stockés dans la table Employés.

En raison des différents systèmes de l'entreprise et des groupes au sein de l'entreprise qui ne communiquent pas entre eux, certains employés temporaires deviennent des employés permanents. Nous avons donc besoin d'un moyen de rendre count de tous les ordres effectués par un nouvel employé permanent. «employés temporaires» et techniquement «merge» datatables que l'employé temporaire a travaillées sur son nouveau dossier d'employé permanent.

Tous les employés temporaires ne deviendront pas des employés permanents. Toutes les commands doivent être associées à un «employé», c'est-à-dire une key étrangère contenant l'identifiant unique de l'employé.

Je suis coincé sur la façon d'intégrer le concept d'un «employé temporaire» dans ce model de données et de maintenir l'intégrité des données avec les commands. Aucune suggestion?

Structure de la table DB actuelle:

Employé

EmployeeID (PK)
Prénom
Nom de famille
… autres attributes

Commande

OrderID (PK)
EmployeeID (FK)
… autres attributes

MISE À JOUR 1: Lorsque j'ai essayé de transmettre ce problème dans une design de table de database, c'est lorsque j'ai décidé de requestr l'avis des experts en SO. Dans mon parsing d'une solution via OOP, une design d'un [TempEmployee] est un [employé], mais je n'étais pas en mesure d'envelopper mon cerveau sur la façon de transmettre cela dans la design de table et les opérations CRUD. FYI, un [Employé] a beaucoup de champs alors qu'un [TempEmployee] a un sous-set de ces champs, ainsi tous ses champs existent dans un Employé.

(Je suppose qu'il est possible de charger des employés temporaires en tant qu'employés)

L'inheritance est un scénario assez commun dans la modélisation – dans votre cas, il semble que vous pouvez étendre la structure existante des employés, de sorte que vous pouvez modéliser les employés temporaires comme suit:

TemporaryEmployee - EmployeeID (PK and FK to Employee) - StartDate - EndDate - Other temp employee fields here

Étant donné que TemporaryEmployee IS est également un Employee , il partage la key primaire Employee et l'intégrité référentielle peut être appliquée en faisant de TemporaryEmployee.EmployeeId une key étrangère à Employee.EmployeeId .

L'intégrité des Orders n'est pas affectée, puisque le RI Employees-Orders existant est inchangé. Un autre avantage de l'extension plutôt que de l'évolution est que vous n'avez pas modifié le model sous-jacent, donc les problèmes de régression causés par votre changement dans votre système ERP devraient être évités (bien que les tests soient toujours essentiels).

Modifier, clarification:

Tables système ERP existantes:

 CREATE TABLE Employee ( EmployeeID INT identity(1,1) NOT NULL PRIMARY KEY, EmployeeTypeId ? -- eg might be able to repurpose to identity Temporary employees? -- Other Employee Fields here ... not all of these will be relevant to TemporaryEmployee ); CREATE TABLE Orders ( OrderId INT identity(1,1) NOT NULL PRIMARY KEY, EmployeeID INT NOT NULL FOREIGN KEY REFERENCES Employee(EmployeeID) -- etc. );

Maintenant, vous étendez Employee avec une autre table, sans modifier le schéma ci-dessus:

 CREATE TABLE TempEmployee ( EmployeeID INT NOT NULL PRIMARY KEY, -- Other extended fields here as per above CONSTRAINT FK_TempEmployee_Employee REFERENCES Employee(EmployeeID) );

Vous pouvez append un champ d' status sur votre table Employee qui indique si l'employé est à time plein ou à time partiel. Créez une autre table comme:

 create table temp_change_date ( employeeID int PK (FK), change_date date );

Remplissez cette table avec un update sortinggger sur votre table Employee lorsqu'un employee passe de temporaire à permanent.

De cette façon, les Orders automatiquement mappées et vous pouvez voir toutes les commands créées alors qu'elles étaient des employés temporaires utilisant la date à laquelle elles ont été modifiées.