Каков наилучший способ реализации отношений "многие ко многим" с использованием ORMLite?
В настоящее время я играю с ORMlite, чтобы создать модель с таблицами и отношениями.
Одна взаимосвязь - это отношения "многие ко многим". Какой лучший способ реализовать это?
Чтобы быть более конкретным:
Скажем, у меня есть эти две таблицы
Product
id
brand
Purchase
id
Закупка может иметь несколько продуктов, и один продукт может быть в нескольких покупках.
Используя ORMLite, я мог бы иметь @ForeignCollectionField
в каждой модели, но я не думаю, что это сработает.
Единственное допустимое решение, которое я вижу, - это сделать третью таблицу Product_Purchase, чтобы связать Product и Purchase со многими-к-одному.
Что вы думаете?
Ответы
Ответ 1
@Romain self answer is correct, но здесь есть дополнительная информация для потомков. Как он упоминает, есть пример многостранового ORMLite, который демонстрирует лучший способ сделать это:
http://ormlite.com/docs/example-many
В примере используется таблица соединений с идентификатором обоих объектов для хранения отношения. В вопросе @Romain объект объединения будет иметь как объект Product
, так и Purchase
. Что-то вроде:
public class ProductPurchase {
@DatabaseField(generatedId = true)
private int id;
@DatabaseField(foreign = true)
private Product product;
@DatabaseField(foreign = true)
private Purchase purchase;
...
}
Поля id извлекаются из объектов, которые создают таблицу типа:
CREATE TABLE `userpost` (`id` INTEGER AUTO_INCREMENT , `user_id` INTEGER ,
`post_id` INTEGER , PRIMARY KEY (`id`) )
Затем вы используете внутренние запросы для поиска объектов Product
, связанных с каждым Purchase
и наоборот. См. lookupPostsForUser()
метод в примере проекта для деталей.
Произошло некоторое размышление и дизайн, делающий это автоматически, но прямо сейчас ORMLite обрабатывает внутренние отношения "один ко многим".
Ответ 2
Хорошо. Думаю, единственный способ - создать третью таблицу Product_Purchase.
Он указан в примерном проекте.
Ответ 3
Вам необходимо создать класс ProductPurchase и управлять им, как и другим объектом, который должен войти в вашу базу данных.
Вы можете (но вам не обязательно) иметь коллекцию продуктов внутри покупок (и наоборот), но их придется вручную обновлять/создавать, когда вы загружаете отношения между Продуктами и Покупками из компоновщика ProductPurchase Таблица. Наличие этих коллекций ничего не значит для ORM (вы не должны и не должны комментировать их).
Если кто-то ищет и приложение для Android с отношениями "многие-ко-многим", я работал над примером:
https://github.com/arthurrauter/ormlite-android