我有一个设计/编程问题。首先,我想问一下我的设计是否良好然后我想知道如何。
我想做的是拥有一个i18n页面,可能有也可能没有翻译。例如Page A有英文&日语和Page B可能只有英语
这是数据库布局
page
----
id int
topic varchar(128)
content varchar(1024)
page_l10n
---------
id int fk
topic varchar(128)
content varchar(1024)
locale_id int fk
locale
------
id int
name varchar(8)
要选择,我会做这样的事情
SELECT
COALESCE (hl.topic,h.topic) , COALESCE(hl.content, h.content)
FROM page h
LEFT JOIN (page_l10n hl, `locale` l) ON (h.id=hl.id AND l.id=hl.locale_id) AND l.locale = 'ja_JP'
所以我的问题是,如果这是一个正确的数据库布局(或者你们建议只使用2个表并将语言环境作为页面表中的列?或其他方式吗?),我该怎么办?做我的模特(POJO)?
我正在使用JPA进行R / O映射,并使用hibernate进行数据库连接。
请告知 提前谢谢〜
答案 0 :(得分:1)
我将假设您的内容是动态的(例如,由最终用户提供/更改)。如果不是,您可能需要查看resource bundles。
如果不了解您要实现的目标并且您提供的描述很少,则很难批评您的数据库布局。但是,假设topic
和content
是您的网页将拥有的唯一属性,并且两者都需要进行本地化,我建议如下:
1 id
表的page
列看起来是一个代理键(因为它是int
类型),如果从其他表中引用它就没问题。但是,如果您要直接检索页面内容,则需要一些方法来处理页面而无需对其ID进行硬编码(我的意思是如果我需要获取some/path/pageA.html
的内容,我怎么知道我应该查找ID = 173的页面?)因此,如果是这种情况,您可能也想在该表中存储一个自然键。
2)我不确定topic
表中是否需要content
和page
列;为什么不将它们存储在page_l10n
中以获取适当的区域设置?有些情况下将它们保存在page
表中可能是合适的,但我不认为你的是其中之一。
3)如果您只想支持翻译到有限的语言环境子集而不是所有可用的语言环境,那么拥有单独的locale
表可能是有意义的。
就映射而言,JoinTable注释主要用于多对多映射或(有些不常见)单向一对多映射;它们都不适用于您的情况。从孩子的角度来看,你需要一个简单的collection托管。有点像:
// in your Page class
@OneToMany(mappedBy="page")
public List<PageLocalization> getPageLocalizations() {
// in your PageLocalization class
@ManyToOne
public Page getPage() {