设计数据库架构：用于多种不同语言的数据库

发布于 2024-09-12 17:00:19 字数 559 浏览 5 评论 0原文

我有一个网站，应该将相同内容翻译成不同的语言。因此它应该具有相同字符串的不同翻译的数据库条目。它不只是一个小网站，所以有很多不同的复杂数据结构。

我有一个想法如何实现这一点。但我真的不喜欢它。

我想引入一个额外的翻译表，其中计划存储不同语言的字符串字段。

例如，对于表 Project，包含三个字符串字段（name、shortDescr、fullDescr），我将以下面的方式使用翻译表：

alt text http://a.imageshack.us/img576/7948/2deldbtop.png

我会将 name、shortDescr、fullDecr 字段从字符串更改为整数（包含链接（ID ) 到翻译TxtID)。不同的translationTxtID和lang字段将为每个字符串标记和语言定义唯一的字符串。所以这个解决方案是可行的，但我正在寻找更优雅的解决方案。你能建议我解决这个问题吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

方圜几里 2024-09-19 17:00:19

你能建议我解决这个问题吗？

是的。

不要使用整数键。事实上，这不是你自己发明的。只需使用gettext。您已经可以在几乎所有操作系统上使用它了。它是快速且经过验证的软件，您无需编写。

执行标准 gettext 模块为 i18n 所做的操作。（参见http://en.wikipedia.org/wiki/GNU_gettext）

使用文本键。
选择一个区域设置（即“C”区域设置，或您编写软件的区域设置）。
将所有消息作为默认区域设置中的字符串放入“项目”表中。
将所有翻译与原始字符串和要翻译的 I18N 语言环境一起放入“翻译”表中。是的，翻译表由一个又大又长的字符串作为键。这在实践中非常有效，因为（1）你没有那么多字符串，（2）你不经常查找它们，（3）你应该使用 gettext，而不是滚动你自己的字符串。
当您向用户呈现任何数据时，您会尝试执行 SELECT 来获取翻译。如果您找到翻译，那就太好了。
如果您找不到翻译，那么他们会告诉您您使用的是默认字符串，这总比没有好。将异常记录在某处，并显示原始字符串。

回复收藏 0 原文

孤独患者 2024-09-19 17:00:19

为什么表中不包含多个条目，每个语言对应一个条目？ PK 可以是 ID 和 LangID 的组合。对于上面的示例：

Project

ID, int
LangId, int
Name, varchar
shortDesc, varchar
Fulldesc, varchar
date, date

然后，您在代码中需要做的就是设置一个语言变量，并在查询中将其作为查询中的一个选项提供（我在这里使用 SQL 作为参考）：

SELECT (columns)
FROM Project
WHERE ID = @id
and LangId = @langid

您可以在所有查询中保持 langid查询该特定会话。

Why not have multiple entries in the tables, one for each lang? The PK can be a combo of ID and LangID. For your example above:

Project

ID, int
LangId, int
Name, varchar
shortDesc, varchar
Fulldesc, varchar
date, date

Then all you need to do in your code is set a language variable, and in your queries feed it as one option in the query (I'm using SQL as a reference here):

SELECT (columns)
FROM Project
WHERE ID = @id
and LangId = @langid

You keep langid through all the queries for that particular session.

回复收藏 0 原文

耶耶耶 2024-09-19 17:00:19

我为每个包含字符串的父表使用本地化表。因此，如果您有一个表“Project”，那么您也会有一个表“Project_Locale”。 Project_Locale 与 Project 具有相同的 PK + 增加了“文化”字段。所有可本地化的字符串字段都放在 Project_Locale 中，其他所有内容都放在 Project 中。

回复收藏 0 原文

白色秋天 2024-09-19 17:00:19

我的选择是

Project
-------
ProjectID (PK)
Date

ProjectLoc
----------
ProjectID (FK)
Lang
Name
ShortDesc
FullDesc

然后您可以运行一个简单的查询，例如

SELECT Project.ProjectID, Date, Name, ShortDesc, FullDesc
FROM Project
LEFT JOIN ProjectLoc ON Project.ProjectID = ProjectLoc.ProjectID
WHERE ProjectLoc.Lang = %CurrentLang%

优点：优雅而简单
缺点：大量表格

My choice is

Project
-------
ProjectID (PK)
Date

ProjectLoc
----------
ProjectID (FK)
Lang
Name
ShortDesc
FullDesc

Then you can run a simple query like

SELECT Project.ProjectID, Date, Name, ShortDesc, FullDesc
FROM Project
LEFT JOIN ProjectLoc ON Project.ProjectID = ProjectLoc.ProjectID
WHERE ProjectLoc.Lang = %CurrentLang%

Pros: Elegant and simple
Cons: Large number of tables

回复收藏 0 原文