Sprachübersetzung für Tabellen

Question

Ich weiß, dass die meisten Leute den folgenden Ansatz verwenden und eine Übersetzungstabelle für die spezifische Tabelle erstellen, die Übersetzungen benötigt, aber dies kann zu einer Last von Tabellen führen.

CREATE TABLE Product 
(
    Product_id 
    ,ProductTrans_id -- FK 
) 

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

Wäre der folgende Ansatz machbar? Angenommen, Sie haben viele Tabellen, in denen mehr als eine Spalte übersetzt werden muss. Könnten Sie folgendes tun und alle Übersetzungen in einer Tabelle behalten? Ich nehme an, dass dieser Tisch im Laufe der Zeit enorm an Größe zunehmen würde.

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

den zweiten Ansatz So verwenden Sie würde den Text wie erhalten so

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

Ich bin nicht sicher, warum Sie über die Anzahl der Tabellen betroffen sind: weniger Tabellen bedeutet nicht automatisch Ihre Datenbank ist kleiner, effizienter oder besser gestaltet. Besonders wenn die Anzahl der Tabellen die Komplexität Ihrer Abfragen erhöht, wäre ich sehr vorsichtig damit.

Wie auch immer, ich würde für eine Übersetzungstabelle pro Basistabelle gehen. Der Hauptgrund ist, dass Ihre zweite Lösung nicht flexibel ist: Wenn der Primärschlüssel keine einzelne ganze Zahl ist, wird es extrem schwierig zu implementieren und zu verwenden. Das Abfragen von Übersetzungen ist ebenfalls komplexer und abhängig von der Größe der Tabelle und der Daten kann es schwierig sein, sie effektiv zu indizieren.

Es ist nicht klar, warum Sie eine TranslationID auf der Products Tabelle haben; in der Regel ist das Verhältnis umgekehrt:

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

Je nach Toolset und Bereitstellungsprozess Sie Übersetzungstabellen erzeugen, direkt von den Basis diejenigen als Teil Ihrer Datenbank aufbauen möchten. Und Sie können Ansichten verwenden, um eine praktische, vollständig übersetzte Version der Basistabelle bereitzustellen.

Eine interessante Frage ist, welche Sprache für die Spalten in Products verwendet wird und ob sie direkt verwendet werden können, wenn keine Übersetzung benötigt wird. Mein Vorschlag wäre, dass der gesamte Produktionscode einen Sprachparameter übergibt und nur den Text aus der Tabelle ProductsTranslations mitnimmt, selbst für Englisch (oder was auch immer Ihre interne Unternehmenssprache ist). Auf diese Weise können Sie sicher sein, dass alle offiziellen Namen in der gleichen Tabelle gefunden werden. Die Spalten in der Basistabelle dienen der Übersichtlichkeit und Vollständigkeit des Datenmodells sowie der Entwicklerfreundlichkeit und (möglicherweise) internen Verwendung auf Ad-hoc-Basis Berichte und so weiter.