database design - table with multiple nullable foreign keys
I can't see the entire data model or exactly the context of &quot;Operation&quot; so I can't tell you if there's a better solution, but in general the second approach is preferable, any complexities it creates can be handled by creating a view that creates a simple presentation of the data without requiring someone to even ponder the joins that occur behind the scenes.  Any insert/update/delete procedures only need to be programmed once, the additional complexity will be minimal.
Yes, more tables... BUT:

Those tables will be narrow and small.
You would probably build some sort of filtered index on those columns to facilitate searches, and they would look remarkably identical to the tables you've created.  But in creating them you give more meaning to them than just breaking rules that exist for a good reason in order to save a few lines of code.
If in the future OperationTarget not has more &quot;targets&quot;, much easier to add another table instead of more columns to the base table.

I'd also look harder at this to see if this is a good application for exclusive subtypes, as I said I don't have a full picture of your data model so it would be something you'd have to evaluate on your own.