У меня есть один - многие отношения в моем локальном дб Sqlite. Довольно основной материал. Когда я делаю свое левое внешнее объединение, я возвращаю результаты, которые похожи на это:
получающийся курсор имеет несколько строк, которые похожи на это:
A1.id | A1.column1 | A1.column2 | B1.a_id_fk | B1.column1 | B1.column2
A1.id | A1.column1 | A1.column2 | B2.a_id_fk | B2.column1 | B2.column2
и так далее...
Существует ли общепринятая практика или метод контакта с результатами как это? Очевидно существует только A1, но он имеет много отношений B-n. Я близко подхожу к использованию нескольких запросов вместо "реляционного дб путь". Надо надеяться, я просто не знаю о лучшем способе сделать вещи.
Я намереваюсь выставить этот запрос через контент-провайдера, и я не хотел бы во всех потребителей должным быть записать ту же логику агрегирования.
Соединения работали таким образом в каждой базе данных SQL, которую я когда-либо использовал - это своего рода определение концепции.
Имейте в виду, что провайдеры контента используют удаленные вызовы процедур, что требует больших затрат. Это одна из причин, по которой Android денормализует результаты по тем же принципам, что и ваше соединение для таких вещей, как контакты, чтобы минимизировать круговые обходы между процессами.
Вы можете рассмотреть возможность использования удаленной службы вместо поставщика контента и предоставления настраиваемого API. Вы можете вернуть B для данного A с помощью простого List <>
. Или вы можете сериализовать все это в формате JSON. Или любое количество других возможностей, если дублирование данных вас беспокоит.