テーブルの言語翻訳

テーブルの数について心配している理由がわかりません。テーブルの数が少ないからといって、データベースがより小さく、より効率的になり、より適切に設計されているとは限りません。特に、テーブルの数を減らすとクエリが複雑になる場合は、慎重に行う必要があります。

とにかく、私は「ベース」テーブルごとに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からテキストを取得する必要があるということです。表のみ、英語（または社内の企業言語が何であれ）の場合でも。そうすれば、すべての「正式な」名前が同じテーブルにあることを確認できます。ベーステーブルの列は、データモデルの明確さと完全性、開発者の利便性、および（場合によっては）アドホックでの内部使用のためにあります。レポートなど。