To give an idea of what I'm talking about, consider an entity (in my case, it's a `Task`) which could be linked to any number of other entities in the system. For our purposes let's say the task could be linked to:

* Project
* Account
* Ticket
* Person
* etc

All of these are represented with their own tables in the database. Now, a task could potentially be linked to any one of those, and due to the system being in active development, the list of potential links will continue to grow relatively quickly. Note these are 1 to many relationships - a task can only be linked to one of these at a time, but a single Account could have multiple tasks tied to it.

Now, I have considered a few options for this, however I do not consider myself any kind of expert in database design, so I figured I'd reach out. Options I've considered thus-far include:

* A foreign key for each link in the `Task` table, and we just have to keep adding columns. However since a task cannot be linked to more than one of them at a time, this will result in a lot of FK columns with NULL values. This also will require a new column and regeneration of our database model in our application whenever we add a new link.
* A single column in `Task` that acts as a foreign key, but include another column specifying a link `type`, so when querying against it we can determine which JOINs happen based on type. So both Account's and Person's IDs would be in this column for their tasks, but the link type column would specify whether the ID is a person or an account. This feels very risky to me and obviously the constraints can't be enforced by the database..
* Other options??

I would love if someone was able to point me in the direction of a "cleaner" design, but if not, would the multiple columns acting as FK constraints, but allowing NULL be the best bet?

Thanks in advance!