My traditional schema was always to have id in every table and to make it an integer, then for pretty much anything it'd be two tables, nouns for the thing and

My traditional schema was always to have id in every table and to make it an integer, then for pretty much anything it'd be two tables, nouns for the thing and a one-to-many relationship with noun_names for the names, where noun_names was comprised of id/noun/language/name, keyed on noun and language, with the language column FK'd to languages.id. I'd also have a languages.code column for ISO or IANA code (sometimes both columns or aliases), and a language_names table with language_used/language_named. So you could name English in Frisian, and Chinese in Tibetan. Haven't needed to build SQL in ages, though that schema works great. Certainly never had an issue with it once UTF-8 became standard. If you build schemas without i18n, you're asking for trouble. One good thing about using a standard integer key is the cost of indexes is low (low memory use). One good thing about using id everywhere is that it's short and self-explanatory to programmers from any culture. Lots of casual queries built of subqueries like... select * from noun_names where noun=(select id from nouns where ...) and language=(select id from language where code='en'); Always felt this was the most readable. Always felt that LEFT/RIGHT JOIN stuff was bonkers. Onboarded a lot of serious junior devs, never had an issue.