うまくいけば、CTE (mySQL を除くほぼすべて) をサポートする RDBMS を使用しているか、結合されたテーブルを毎回参照するようにこれを変更する必要があります...
WITH Translations (attribute_id, text)
as (SELECT c.attribute_id, t.tra_text
FROM Country_Translations c
JOIN Text_Translations t
ON t.trans_text_id = c.att_text_id
WHERE c.att_language_id = @languageId)
SELECT Products.prod_id,
Type.text,
Color.text,
Weight.text,
Price_Range.text
FROM Products
JOIN Translations as Type
ON Type.attribute_id = Products.pro_type_id
JOIN Translations as Color
ON Color.attribute_id = Products.pro_color_id
JOIN Translations as Weight
ON Weight.attribute_id = Products.pro_weight_id
JOIN Translations as Price_Range
ON Price_Range.attribute_id = Products.pro_price_range_id
もちろん、個人的には、ローカリゼーション テーブルの設計は 2 つの点で失敗したと思います。
- すべてが同じテーブルにあります (特に「属性タイプ」列がない場合)。
- 言語属性が間違ったテーブルにあります。
1) の場合、すべての属性値のシステム全体での一意性を維持する必要があるため、これはほとんど問題になります。ある時点で、「重複」に遭遇することはほぼ保証できます。また、多くの空き領域を使用して範囲を設計していない限り、データ値はタイプに対して連続していません。注意しないと、指定された範囲の開始と終了が同じ属性に属しているが、範囲内のすべての値ではないという理由だけで、更新ステートメントが間違った値に対して実行される可能性があります。
2) については、テキストをその言語 (および国の「ロケール」) から完全に切り離すことはできないためです。私が理解していることから、複数の言語で書かれたものとして有効なテキストの一部がありますが、
ローカライゼーションを次のようなものに保存する方がよいでしょう (ここに示されているのは 1 つの表のみで、残りは読者の演習です)。
Color
=========
color_id -- autoincrement
cyan -- smallint
yellow -- smallint
magenta -- smallint
key -- smallint
-- assuming CYMK palette, add other required attributes
Color_Localization
===================
color_localization_id -- autoincrement, but optional:
-- the tuple (color_id, locale_id) should be unique
color_id -- fk reference to Color.color_id
locale_id -- fk reference to locale table.
-- Technically this is also country dependent,
-- but you can start off with just language
color_name -- localized text
これにより、すべての属性が独自の ID セットを持つようになり、ローカライズされたテキストがローカライズされたものに直接関連付けられるようになります。