This is a bad design. Just make a 2-column primary key, and 2-column foreign keys to it. This is a fundamental anti-pattern called “encoding information in keys” which (thereby) are called “smart”, “intelligent” or “concatenated” keys. A good key is a “dumb” key.
Eg::
Despite it now being easy to implement a Smart Key, it is hard to
recommend that you create one of your own that isn’t a natural key,
because they tend to eventually run into trouble, whatever their
advantages, because it makes the databases harder to refactor, imposes
an order which is
difficult to change and may not be optimal for your queries, requires
a string comparison if the Smart Key includes non-numeric characters,
and is less effective than a composite key in helping range-based
aggregations. It also violates the basic relational guideline that
every column should store atomic valuesSmart Keys also tend to outgrow their original coding constraints
Besides, there is no need to do this.
Many DBMSes allow “computed columns” whose values are automatically calculated from other columns. To make one a primary key or foreign key you would usually need it “persisted”, ie have take up memory like a normal column vs just being calculated when needed like a view. MySQL does not have these, but 5.7.5 has some functionality where they are called “generated columns”, which can be “stored”. But don’t do this for PKs or FKs!
The actual design issue is handling database/SQL subtypes/hierarchies/inheritance/polymorphism.