Reputation: 35684
There's bunch of items that require translations, and I have three tables. Languages
, Fruits
and FruitNames
this is the code I would use (in ms SQL)
CREATE TABLE [FruitNames] (
[LanguageId] INT NOT NULL ,
[FruitId] INT NOT NULL ,
[name] NVARCHAR( 100 ) NOT NULL ,
FOREIGN KEY (LanguageId) REFERENCES Languages(id),
FOREIGN KEY (FruitId) REFERENCES Fruits(id),
PRIMARY KEY ([LanguageId],[FruitId])
)
Assuming that I will never require two names of the same language for one item, Is there an advantage to using a composite key?
Upvotes: 2
Views: 89
Reputation: 10941
Seems like a pretty good candidate for a composite key to me. I can't speak for overall scalability, but if all you're translating is the fruit's name, this should be fine.
Upvotes: 1