EF Core Inheritence: Using same FK column for multiple relations

I'm currently working on a ticket system where it should be possible to link documents to the ticket. There are different types of tickets, and each has it's own document table connected to it. The document table itself stores some meta information about the document as well as having a relation to the ticket itself. The meta information is the same, so the only difference is the different relations.

The issue that is rising is the number of ticket types are growing, hence also my document tables. To limit the need for more tables, I would like to merge all documents into one table and at the same time making it easy to add new ones in the future.

I've looked into using inheritance, more specifically Table-per-hierarchy approach, but I've got a bit stuck and are hoping someone can guide me in the right direction.

// This is my main class where all shared properties are defined
// I also plan to use this for documents that are just connected to a customer and not a ticket
public class CustomerDocumentsModel : EntityBase
{
	[Required]
	[Column("customer_id")]
	[MaxLength(24)]
	public string CustomerId { get; set; }

	[Required]
	[Column("file_name")]
	[MaxLength(500)]
	public string FileName { get; set; }

	// ... other shared properties
}

// I also have this setup in my OnModelCreating
modelBuilder.Entity<CustomerDocumentsModel>().HasDiscriminator<string>("document_type");

// This is my generic class that should link a documents relation to the other table
public class CustomerDocumentType<T> : CustomerDocumentsModel
{
	public virtual T ExternalEntity { get; set; }

	[Column("fk_external_id")]
	[ForeignKey(nameof(ExternalEntity))]
	public int? FKExternalId { get; set; }

	[Required]
	[Column("external_type")]
	public string ExternalType { get; set; } = typeof(T).Name;
}

// And I create the generic tables with the ticket relation like this
public class CustomerDocumentsAML : CustomerDocumentType<AMLTicketModel> { }
public class CustomerDocumentsDisputes : CustomerDocumentType<DisputeTicketModel> { }

So far so good. I can create a migration and apply it to my db but this is where things becomes tricky. When I try to insert my different type of documents (except ones that are not connected to a specific ticket) I get a violation of foreign key constraint.

The cause of this as some of you probably have guessed is because I've reused the same FK column for all of my different type of documents. So when I try to connect a AMLTicketModel of 9001, I get an error because there are no ID that correspond in DisputeTicketModel. This is where I start to realise I might be into implementing a anti-pattern, but code wise this approach is to neat to give up on yet.

I've searched the web and the closest I have come is two options to solve my issue.

1. Have a unique FK column for each type

Where this approach would be quite easy to do with low amount of overload, it would result in my document table having a lot of null columns real fast. Maybe not bad from a performance point of view, but it would most likely cause a ophthalmia for anyone querying it directly.

2. Ignore the usage of FK and make the connection in the ticket

So instead of defining my column as a FK, I would instead make the connection something like this:

modelBuilder.Entity<AMLTicketModel>()
	.HasMany(x => x.Documents)
	.WithOne()
	.HasPrincipalKey(x => x.Id)
	.HasForeignKey(y => y.ExternaltId);

This would result in a lot of work every time a new type is added since all connection has to be done manually. It would also result that I can no longer fetch a document directly and get the connected ticket from that way (without doing more manual stuff)

I have quite the need of having neat and dynamic code, so does anyone have a cleaver idea how I can solve my problem? If not I'll have to pick one of the above at random, so please help

So an update if anyone find this question in the future and are interested in a potential solution (if somewhat hacky).

I modified my generic class slightly and made all the connection by annotations. Creating of the models are primarily also made through the constructor so we can reuse the base constructor as well.

[Index(nameof(ExternalId), IsUnique = false)]
public abstract class CustomerDocumentsModel<T> : CustomerDocumentsModel
{
    public CustomerDocumentsAMLModel() : base() { }

    public CustomerDocumentsAMLModel(/* params */) : base(/* params */)
    { }

    [Column("external_id")]
    [ForeignKey(nameof(ExternalEntity))]
    public int? ExternalId { get; set; }

    public virtual T ExternalEntity { get; set; }
}

By using the annotations we are setting up the connection in a simply way that will also automatically be added if a new document type is added in the future. In the migration however one always needs to remember to remove the actual foreign key generation. If we remove it, no FKs will be created in the SQL, but all connections still exists in EF and can therefore still work it's magic.

// Remove all appearances of this
table.ForeignKey(
    name: "FK_CustomerDocuments_AMLTickets_external_id",
    column: x => x.external_id,
    principalTable: "AMLTickets",
    principalColumn: "id");

I also added a document type (enum) in my base class that is used in combination with a factory to generate the correct model when creating the object. As long as I generate the document with the correct model, EF will take care of the rest when quering.

public static class CustomerDocumentFactory
{
    public static CustomerDocumentsModel Create(/* dto */)
        => dto.DocumentType switch
        {
            CustomerDocumentType.General => 
                new CustomerDocumentsModel(/* params */),
            CustomerDocumentType.AMLDocument =>
                new CustomerDocumentsAMLModel(/* params */),
            // ... etc
    };
}

This surely breaks some best practices and principles, but it works. Hope you find it helpful!