Language Translation for Tables

Question

So che la maggior parte delle persone utilizza l'approccio seguente e crea una tabella di conversione per la tabella specifica che necessita di traduzioni, ma questo può essere un carico di tabelle.

CREATE TABLE Product 
(
    Product_id 
    ,ProductTrans_id -- FK 
) 

CREATE TABLE ProductTranslation 
(
    ProductTrans_id 
    ,Product_id 
    ,Name 
    ,Descr 
    ,lang_code 
) 

L'approccio di seguito potrebbe essere valido? Supponiamo che tu abbia molte tabelle in cui è necessario tradurre più di 1 colonna. Potresti fare quanto segue e mantenere tutte le traduzioni in 1 tabella? Suppongo che questo tavolo crescerà enormemente nel tempo.

CREATE TABLE translation_entry (
      translation_id  int, 
      language_id   int, 
      table_name   nvarchar(200), 
      table_column_name  nvarchar(200), 
      table_row_id   bigint, 
      translated_text  ntext 
     ) 

    CREATE TABLE translation_language (
      id int, 
      language_code CHAR(2) 
     ) 

Quindi, utilizzando il secondo metodo si otterrebbe il testo in questo modo

select 
    product.name 
    ,translation_entry.translated_text 
from product 
inner join translation_entry on product.product_id = translation_entry.table_row_id 
and translation_entry.table_name = 'Product' and translation_entry.table_column_name = 'Name' 
and language_id = 3 

Answer 1

io non sono sicuro perché sei preoccupato per il numero di tavoli: avere meno tavoli non significa automaticamente il tuo database è più piccolo, più efficiente o meglio progettato. Soprattutto se ridurre il numero di tabelle aumenta la complessità delle tue query, sarei molto attento a farlo.

In ogni caso, vorrei andare per una tabella di traduzione per tabella 'base'. Il motivo principale è che la seconda soluzione non è flessibile: se la chiave primaria non è un singolo numero, diventa estremamente difficile da implementare e utilizzare. Anche la ricerca delle traduzioni è più complessa e, a seconda delle dimensioni della tabella e dei dati, potrebbe essere difficile indicizzarla in modo efficace.

Non è chiaro il motivo per cui si dispone di un TranslationID nella tabella Products; di solito il rapporto è il contrario:

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

A seconda del set di strumenti e processo di distribuzione è possibile generare tabelle di conversione direttamente da quelle di base come parte della vostra generazione del database. E puoi usare le viste per fornire una versione comoda, "completamente tradotta" della tabella di base.

Una domanda interessante è la lingua utilizzata per le colonne in Products e se possono essere utilizzate direttamente quando non è richiesta alcuna traduzione. Il mio suggerimento sarebbe che tutto il codice di produzione dovrebbe passare un parametro di lingua e prendere il testo solo dalla tabella ProductsTranslations, anche per l'inglese (o qualunque sia la lingua aziendale interna). In questo modo puoi essere certo che tutti i nomi "ufficiali" si trovano nella stessa tabella, e le colonne sulla tabella di base sono lì per chiarezza e completezza del modello di dati, nonché la praticità dello sviluppatore e (eventualmente) l'uso interno su ad hoc rapporti e così via.