Microsoft SQL Server - comment appliquer uniquement la clé étrangère lors de l'insertion, mais permettre aux clés étrangères orphelines de rester?

Question

Voici les technologies utilisées pour le développement local:

• Microsoft SQL Server 2016 Web Edition

Disons que je le tableau suivant appelé CarCompanyTable

create table CarCompanyTable(

[CarCompanyid] uniqueidentifier DEFAULT newsequentialid() NOT NULL, 
    [CarCompanyName] [nvarchar](200) NOT NULL, 
    [AddressOfLocation] [nvarchar](200) NOT NULL, 
    CONSTRAINT [PK_CarCompanyid] PRIMARY KEY CLUSTERED (CarCompanyid) 
); 

Disons que J'ai une autre table appelée CarTable

create table CarTable(

[CarId] uniqueidentifier DEFAULT newsequentialid() NOT NULL, 

[CarName] [nvarchar](200) NOT NULL, 
[FKCarCompanyid] uniqueidentifier, 

CONSTRAINT [PK_CarId] PRIMARY KEY CLUSTERED (CarId), 
CONSTRAINT [FK_CarCompanyTableCarTable] FOREIGN KEY(FKCarCompanyid) REFERENCES [dbo].[CarCompanyTable] (CarCompanyid), 
); 

Comment la contrainte extérieure soit appliquée de telle manière que

1) vérifie si CarCompanyid clé étrangère existe sur une nouvelle entrée d'insertion dans le Cartable

2) permet toutefois qu'il y ait orphelin CarCompanyid étranger clé dans le cas où une entrée CarCompanyTable (avec des entrées CarTable correspondantes) est supprimée du CarCompanyTable

Quelqu'un pourrait me dire les modifications exactes que je devrais faire afin de s'assurer que les conditions susmentionnées sont remplies?

Answer 1

Il y a 2 stratégies que la plupart des gens suivent:

1. Modifier le Cartable d'avoir une colonne "IsInactive". Cela vous permet de marquer les enregistrements comme "Supprimés" sans les supprimer. Cela vous permet d'utiliser des clés étrangères normales pour l'intégrité. Bien sûr, cela signifie que vous devez programmer en conséquence, pour afficher uniquement les enregistrements non supprimés (IsInactive = False). N'utilisez pas de clé étrangère pour l'intégrité référentielle. Au lieu de cela, utilisez un déclencheur "sur insertion" pour rechercher (pseudo) les enregistrements FK et lancer une erreur pour appliquer l'intégrité référentielle. Je pense que la plupart des DBA vous diraient que c'est une mauvaise idée et vous devriez rester aveC# 1.

Le côté vers le bas à l'approche # 2 est, une fois que vous supprimez votre dossier référencé, vous ne pouvez pas dire ce qu'il était, et vous ne pouvez pas le récupérer. Avec l'approche n ° 1, vous avez juste besoin d'écrire votre programme pour filtrer les enregistrements inactifs, mais vous pouvez toujours les rechercher si vous en avez vraiment besoin.