Tłumaczenie języków dla tabel

Question

Wiem, że większość osób korzysta z poniższego podejścia i tworzy tabelę tłumaczeń dla konkretnej tabeli, która wymaga tłumaczeń, ale może to stanowić obciążenie tabel.

CREATE TABLE Product 
(
    Product_id 
    ,ProductTrans_id -- FK 
) 

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

Czy poniższe podejście byłoby wykonalne? Załóżmy, że masz wiele tabel, w których wymaga więcej niż jedna kolumna. Czy możesz wykonać następujące czynności i zachować wszystkie tłumaczenia w 1 tabeli? Przypuszczam, że ten stół z czasem powiększyłby się ogromnie.

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

Więc korzystając z drugiego podejścia byś uzyskać tekst podobnie jak

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

Nie jestem pewien, dlaczego jesteś zaniepokojony liczbą tabel: tabele mają mniej nie oznacza automatycznie, Twoja baza danych jest mniejsza, bardziej wydajna lub lepiej zaprojektowana. Zwłaszcza, jeśli zmniejszenie liczby stołów zwiększa złożoność zapytań, byłbym bardzo ostrożny.

W każdym razie chciałbym wybrać jedną tabelę tłumaczeń na tabelę "podstawową". Głównym powodem jest to, że twoje drugie rozwiązanie nie jest elastyczne: jeśli klucz podstawowy nie jest pojedynczą liczbą całkowitą, niezwykle trudne staje się jego wdrożenie i użycie. Zapytanie o tłumaczenia jest również bardziej skomplikowane, a w zależności od wielkości tabeli i danych może być trudno skutecznie ją zaindeksować.

Nie jest jasne, dlaczego masz TranslationID na stole ; Zazwyczaj związek jest na odwrót:

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

zależności od zestawu narzędzi i procesu wdrażania może chcesz wygenerować tabele konwersji bezpośrednio z bazy te jako część kompilacji bazy danych. Możesz także użyć widoków, aby zapewnić wygodną, ​​w pełni przetłumaczoną wersję tabeli podstawowej.

Jednym z interesujących pytań jest to, jaki język jest używany w kolumnach w Products i czy można z nich korzystać bezpośrednio, gdy tłumaczenie nie jest wymagane. Moja sugestia byłaby taka, że ​​cały kod produkcyjny powinien przekazywać parametr językowy i pobierać tekst tylko z tabeli ProductsTranslations, a także dla języka angielskiego (lub innego języka wewnętrznego firmy). W ten sposób możesz mieć pewność, że wszystkie "oficjalne" nazwy znajdują się w tej samej tabeli, a kolumny w tabeli podstawowej zapewniają klarowność i kompletność modelu danych, a także wygodę dla programistów i (być może) wewnętrzne wykorzystanie w trybie ad hoc. raporty i tak dalej.