Sprogoversættelse til tabeller

Jeg er ikke sikker på, hvorfor du er bekymret over antallet af tabeller:At have færre tabeller betyder ikke automatisk, at din database er mindre, mere effektiv eller bedre designet. Især hvis reduktion af antallet af tabeller øger kompleksiteten af ​​dine forespørgsler, ville jeg være meget forsigtig med at gøre det.

I hvert fald ville jeg gå efter én oversættelsestabel pr. 'base'-tabel. Hovedårsagen er, at din anden løsning ikke er fleksibel:Hvis den primære nøgle ikke er et enkelt heltal, bliver det ekstremt vanskeligt at implementere og bruge. Forespørgsel efter oversættelser er også mere komplekst, og afhængigt af størrelsen af ​​tabellen og dataene kan det være svært at indeksere det effektivt.

Det er ikke klart, hvorfor du har et TranslationID på Products bord; normalt er forholdet omvendt:

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

Afhængigt af dit værktøjssæt og din implementeringsproces vil du måske generere oversættelsestabeller direkte fra de grundlæggende som en del af din databasebuild. Og du kan bruge visninger til at give en praktisk, 'fuldt oversat' version af basistabellen.

Et interessant spørgsmål er, hvilket sprog der bruges til kolonnerne i Products og hvis de kan bruges direkte, når der ikke er behov for oversættelse. Mit forslag ville være, at al produktionskode skulle passere en sprogparameter og tage teksten fra ProductsTranslations kun tabel, selv for engelsk (eller hvad dit interne virksomhedssprog nu er). På den måde kan du være sikker på, at alle 'officielle' navne findes i samme tabel, og kolonnerne på basistabellen er der for klarhed og fuldstændighed af datamodellen samt udviklerbekvemmelighed og (eventuelt) intern brug på ad hoc rapporter og så videre.