Taalvertaling voor tabellen

Ik weet niet zeker waarom u zich zorgen maakt over het aantal tabellen:minder tabellen betekent niet automatisch dat uw database kleiner, efficiënter of beter ontworpen is. Vooral als het verminderen van het aantal tabellen de complexiteit van je zoekopdrachten vergroot, zou ik daar heel voorzichtig mee zijn.

Hoe dan ook, ik zou gaan voor één vertaaltabel per 'basis'-tabel. De belangrijkste reden is dat uw tweede oplossing niet flexibel is:als de primaire sleutel geen enkel geheel getal is, wordt het buitengewoon moeilijk te implementeren en te gebruiken. Het opvragen van vertalingen is ook complexer en afhankelijk van de grootte van de tabel en de gegevens kan het moeilijk zijn om deze effectief te indexeren.

Het is niet duidelijk waarom u een TranslationID heeft op de Products tafel; meestal is de relatie andersom:

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)
)

Afhankelijk van uw toolset en implementatieproces wilt u wellicht direct vanuit de basis vertaaltabellen genereren als onderdeel van uw databaseopbouw. En u kunt weergaven gebruiken om een ​​handige, 'volledig vertaalde' versie van de basistabel te bieden.

Een interessante vraag is welke taal wordt gebruikt voor de kolommen in Products en of ze direct kunnen worden gebruikt als er geen vertaling nodig is. Mijn suggestie zou zijn dat alle productiecode een taalparameter moet doorgeven en de tekst uit de ProductsTranslations moet halen alleen in de tabel, zelfs voor Engels (of wat uw interne bedrijfstaal ook is). Op die manier weet je zeker dat alle 'officiële' namen in dezelfde tabel staan, en de kolommen op de basistabel zijn er voor de duidelijkheid en volledigheid van het datamodel, evenals het gemak van de ontwikkelaar en (mogelijk) intern gebruik op ad hoc rapporten enzovoort.