Don’t mix business data with the technology requirement of uniquely identifying a row. That is, don’t use natural keys. It’s much easier to adapt to unpredictable changes when the data that’s changing hasn’t been used as primary and foreign keys throughout your database.
It sounds like you want to avoid the join for performance reasons. Obligatory root of all evil quote:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
So, program first and foremost for correctness, robustness, clarity, and maintainability. Then profile your application to find the bottlenecks – to find the 3% of your program that is genuinely performance critical – and optimize only in those places.