2009-08-21 2 views
0

У меня вопрос дизайна/программирования. Сначала я хочу спросить, хорош ли мой дизайн, и тогда я хочу знать, как это сделать.Как сделать сопоставление аннотации JoinTable

Что я хочу сделать, так это иметь страницу i18n, которая может иметь или не иметь перевода. например Страница A имеет английский & японский и Page B может иметь только английский

Это макет DB

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' 

Так что мой вопрос, если это макет ok db (или вы, ребята, предлагаете использовать только 2 таблицы и иметь локаль как столбец в таблице страниц или другой способ сделать это?), как мне сделать свою модель (POJO)?

Я использую JPA для отображения R/O и спящего режима для соединения с БД.

Пожалуйста посоветуйте Заранее спасибо ~

ответ

1

Я буду считать, что содержание является динамическим (например, при условии/изменены конечными пользователями). Если это не так, вы можете взглянуть на resource bundles.

Трудно критиковать ваш макет базы данных, не понимая, чего вы пытаетесь достичь, и вы предоставили очень мало описания. Но, предполагая, что topic и content являются только атрибуты ваши страницы будут иметь и оба они должны быть локализованы, я хотел бы предложить следующее:

1) id столбец page таблицы выглядит суррогатный ключ (так как он из int), что прекрасно, если на это ссылается другая таблица. Однако, если вы собираетесь получать содержимое страницы напрямую, вам нужно каким-то образом адресовать страницы без необходимости жесткого кодирования своих идентификаторов (я имею в виду, если мне нужно получить контент для 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() { 
+0

JoinTable используется для отношений 1-N, где элемент может быть в нескольких коллекциях владельцев; это вряд ли «несколько необычно», оставляя таблицу элементов чистой информацией о соотношении. - Andy (DataNucleus) – DataNucleus

+0

@ Andy - Я не уверен, что вы подразумеваете под «отношениями 1-N, где элемент может быть в нескольких коллекциях владельцев». Тот же экземпляр «Родительский» с несколькими свойствами коллекции, содержащими дочерние экземпляры?Вы говорите, что это широко используемое картографирование? Позаботьтесь о двух различных примерах реальной жизни? – ChssPly76

Смежные вопросы