Езиков превод за таблици

Не съм сигурен защо се притеснявате за броя на таблиците:наличието на по-малко таблици не означава автоматично, че вашата база данни е по-малка, по-ефективна или по-добре проектирана. Особено ако намаляването на броя на таблиците увеличава сложността на вашите заявки, ще бъда много внимателен да го направя.

Както и да е, бих избрал една таблица за превод на „базова“ таблица. Основната причина е, че второто ви решение не е гъвкаво:ако първичният ключ не е едно цяло число, тогава става изключително трудно за прилагане и използване. Запитването за преводи също е по-сложно и в зависимост от размера на таблицата и данните може да е трудно да се индексира ефективно.

Не е ясно защо имате TranslationID на Products маса; обикновено връзката е обратната:

create table dbo.Products (
    ProductCode char(10) not null primary key,
    ProductName nvarchar(50) not null,
    ProductDescription nvarchar(100) not null,
    -- other columns
)

create table dbo.ProductsTranslations (
    ProductCode char(10) not null,
    LanguageCode char(2) not null,
    ProductName nvarchar(50) not null,
    ProductDescription nvarchar(100) not null,
    -- other translations
    constraint FK1 foreign key (ProductCode)
        references dbo.Products (ProductCode),
    constraint FK2 foreign key (LanguageCode)
        references dbo.Languages (LanguageCode),
    constraint PK primary key (ProductCode, LanguageCode)
)

В зависимост от вашия набор от инструменти и процеса на внедряване може да искате да генерирате таблици за превод директно от базовите като част от изграждането на вашата база данни. И можете да използвате изгледи, за да предоставите удобна, „напълно преведена“ версия на основната таблица.

Един интересен въпрос е какъв език се използва за колоните в Products и дали могат да се използват директно, когато не се изисква превод. Моето предложение е целият производствен код да предава езиков параметър и да взема текста от ProductsTranslations само таблица, дори и за английски (или какъвто и да е вашият вътрешен корпоративен език). По този начин можете да сте сигурни, че всички „официални“ имена се намират в една и съща таблица, а колоните в основната таблица са там за яснота и изчерпателност на модела на данни, както и за удобство на разработчиците и (евентуално) вътрешна употреба при ad hoc доклади и т.н.