|
|
|
|
|
|
by jayd16
2107 days ago
|
|
|
You can have a table or view of all the ids across your implementations and FK into that. As for how you would model it in the application, in this case you can just normalize across all the possible columns and have the orm build out your mapped object. |
|
|
That's just moving the problem around. That table would have to have a bunch of nullable columns, and there's no way to express the constraint that either these columns are non-null or those columns are non-null, or these columns are non-null when this enum has this value.
I'm guessing you've never seriously used a language with first-class sum types. Yes, you can use hacks to represent sum-typed data in languages that don't have proper sum types, but it's always going to be a hack. It's like saying C has OO support because you can always construct virtual function tables by hand.