5

ほとんどの人が以下のアプローチを使用して、翻訳が必要な特定のテーブルの翻訳テーブルを作成することを知っていますが、これはテーブルの負荷になる可能性があります。

CREATE TABLE Product
(
     Product_id
    ,ProductTrans_id -- FK
)

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

以下のアプローチは実行可能でしょうか？複数の列を翻訳する必要があるテーブルがたくさんあるとします。次のようにして、すべての翻訳を 1 つのテーブルに保持できますか? このテーブルは、時間の経過とともにサイズが非常に大きくなると思います。

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

したがって、2番目のアプローチを使用すると、次のようなテキストが得られます

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
4

1 に答える 1

2

テーブルの数を気にする理由がわかりません。テーブルの数が少ないからといって、データベースが小さく、効率的で、設計が優れているとは限りません。特に、テーブルの数を減らすとクエリが複雑になる場合は、細心の注意を払って実行します。

とにかく、「ベース」テーブルごとに 1 つの変換テーブルを使用します。主な理由は、2 番目のソリューションが柔軟ではないことです。主キーが単一の整数でない場合、実装と使用が非常に難しくなります。翻訳のクエリもより複雑であり、テーブルとデータのサイズによっては、効果的にインデックスを作成することが難しい場合があります。

なぜあなたがテーブルTranslationIDにいるのかは明らかではありません。Products通常、関係は逆です。

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

ツールセットと展開プロセスによっては、データベース構築の一部として、ベース テーブルから直接変換テーブルを生成したい場合があります。また、ビューを使用して、ベース テーブルの便利な「完全に翻訳された」バージョンを提供できます。

興味深い質問の 1 つは、列に使用されている言語とProducts、翻訳が不要な場合に直接使用できるかどうかです。私の提案は、ProductsTranslations英語 (または社内の社内言語が何であれ) であっても、すべての製品コードが言語パラメーターを渡し、テーブルからのみテキストを取得することです。そうすれば、すべての「正式な」名前が同じテーブルにあることを確認でき、データ モデルの明確さと完全性、および開発者の利便性と (おそらく) アドホックでの内部使用のために、ベース テーブルの列が存在します。レポートなど。

于 2012-12-13T23:03:45.213 に答える