Перекрестные объединения баз данных в JPA

#mysql #database #jpa #jpa-2.0 #cross-database

#mysql #База данных #jpa #jpa-2.0 #перекрестная база данных

Вопрос:

Возможно ли выполнять перекрестные объединения таблиц базы данных в JPA?

У меня есть users таблица в одной базе данных, которая имеет внешний ключ к organizations таблице в отдельной базе данных. Обе базы данных находятся на одной физической машине. Теперь MySQL позволяет мне писать запросы, которые охватывают несколько баз данных, но я не уверен, как это сделать с помощью JPA.

@Entity Аннотации на Java POJO не принимают имя базы данных, поэтому нет способа отметить взаимосвязь между базами данных.

Есть ли обходной путь для этой ситуации? Возможно, используя собственный запрос для загрузки присоединяемого объекта?

Ответ №1:

Если MySQL позволяет вам писать SQL-запрос по базе данных, то вы можете использовать этот SQL в собственном запросе в JPA.

Я предполагаю, что вы используете какой-то механизм связывания базы данных? Если это так, то вы должны быть в состоянии отобразить и это. Вы можете установить «схему» в вашей @Table связанной базы данных на имя ссылки.

т.е.

 @Table(name="organizations", schema="org_schema@org_db")
  

Комментарии:

1. 1 Вау, я этого не знал. Это облегчило бы мне жизнь в моем предыдущем проекте. Спасибо, Джеймс!

Ответ №2:

Вы не можете. Поскольку каждая сущность привязана к контексту сохранения, а контекст привязан к базе данных.

Если под базами данных вы подразумеваете схемы на одном сервере, вы можете сделать 2 вещи

  • создайте представление в одной из схем, указывающее на таблицу в другой схеме. Недостатком является то, что вам может потребоваться сопоставить объект дважды (по одному разу для каждой схемы)
  • Создайте представление с объединением и сопоставьте оттуда любые значения, которые вам нужны. Недостатком является то, что объект будет доступен только для чтения.

Если обе схемы находятся в разных базах данных, то вам придется выполнить объединение вручную в вашем коде.

Один вопрос к вам. Упомянутый вами «внешний ключ» — это реальный внешний ключ БД или логический FK?

Комментарии:

1. Это логический FK. И базы данных — это реальные отдельные базы данных MySQL, хотя и на одной физической машине.

2. Вы не сможете выполнить объединение по причинам, указанным выше. Это может иметь смысл, если вы пытаетесь читать из баз данных, которыми управляют из разных приложений или служб (если вы делаете что-то, связанное с SOA). Решение состоит в том, чтобы выполнить объединение в вашем коде.

3. Я использовал первый подход, и он сработал. Я также протестировал производительность запроса join в представлении vs. то же самое для таблиц отдельных баз данных, и они оказались почти одинаковыми.

Ответ №3:

Мы опробовали следующий подход и, похоже, он работает.

1) В аннотациях @Table отсутствует атрибут schema

2) создайте разные файлы orm для объектов, объединенных схемой, в которой они присутствуют.

3) В каждый из файлов orm вы можете добавить «my_schema».

4) Включите файлы orm из вашего соответствующего PUS в persistence.xml

5) И если вам нужны разные базы данных во время тестов, создайте похожие orm-файлы для тестирования и соответствующим образом измените значение в схеме и включите эти orm-файлы в отдельный PU

HTH