希望您使用的是支持 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
当然,我个人认为本地化表的设计有两方面的拙劣——
- 一切都在同一个表中(尤其是没有“属性类型”列)。
- 语言属性在错误的表中。
对于 1),这主要是一个问题,因为您现在必须维护所有属性值的系统范围的唯一性。我几乎可以保证,在某些时候,你会遇到“重复”。此外,除非您设计了具有大量可用空间的范围,否则数据值对于类型而言是不连续的;如果您不小心,更新语句可能会在错误的值上运行,这仅仅是因为给定范围的开始和结束属于同一属性,但不是范围中的每个值。
对于 2),这是因为文本不能完全脱离其语言(和国家/地区“语言环境”)。据我了解,某些文本的某些部分以多种语言编写是有效的,
您最好将您的本地化存储在与此类似的内容中(此处仅显示一个表格,其余表格供读者练习):
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,并将本地化文本与它直接本地化的内容联系起来。