我知道大多数人都使用下面的方法,并为需要翻译的特定表创建翻译表,但这可能会导致大量的表。
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) )
因此,使用第二种方法,您将获得像这样的文本
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
我不确定您为什么担心表的数量:减少表的数量并不能自动意味着您的数据库更小,更高效或设计更好。特别是如果减少表的数量增加了查询的复杂性,我会非常小心。
无论如何,我会为每个“基本”表选择一个转换表。主要原因是您的第二个解决方案不灵活:如果主键不是单个整数,则将很难实现和使用。查询翻译也更加复杂,并且取决于表和数据的大小,可能难以对其进行有效索引。
目前尚不清楚为什么要TranslationID在Products桌子上放东西。通常,这种关系是相反的:
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) )
根据您的工具集和部署过程,您可能希望直接从基础数据库生成转换表,并将其作为数据库构建的一部分。您还可以使用视图来提供基本表的方便的,“完全翻译”的版本。
一个有趣的问题是列中使用哪种语言,Products以及在不需要翻译时是否可以直接使用它们。我的建议是,所有生产代码都应传递语言参数,并且仅从ProductsTranslations表中获取文本,即使是英语(或您所使用的内部公司语言)也是如此。这样,您可以确保在同一张表中找到所有“正式”名称,并且基表中的各列用于确保数据模型的清晰性和完整性以及开发人员的便利性和(可能)临时使用的内部名称报告等等。
ProductsTranslations