Вместо Relation использовать запросы. Самое простое - параметризированный Local View.

Тогда открой одни и те же таблицы несколько раз в разных рабочих областях. Разные копии (разные рабочие области) - для разных закладок. В этом случае не надо будет каждый раз заново настривать Relation при активизации страниц.

Кроме Local View можно использовать CursorAdapter. Ему база данных не нужна. По скорости разницы не заметишь, поскольку в любом случае используются индексы.

Не_проходи_мимоА что более правильно
Такой термин, в данном случае, не уместен. Обычно используют терминам "удобнее".

Есть задача. Он должна быть решена. Решил? Молодец! Как решил? Никого не волнует!

Однако после решения задачи начинается ее сопровождение и развитие. И вот здесь важным оказывается именно способ решения, но не с точки зрения его "правильности", а с точки зрения простоты и удобства внесения нужных модификаций.

Поэтому выбор того или иного решения предполагает (кроме собственно факта решения) еще и удобство сопровождения и модификации. Вот с этой точки зрения и можно попробовать оценить варианты

Не_проходи_мимону напрмер в запросах можно использовать условие where t1.kod=t2.kod, но более правильно это внутренее объединение inner join
Если речь идет об описанной задаче, где первая страница - данные одной таблицы, а вторая страница - данные другой таблцы, то логично использовать именно t1.kod=t2.kod, а вовсе не INNER JOIN. Ведь из главной страницы вам вообще ничего не надо. Нужен только ее идентификатор. Так зачем же "городить" объединение, кода этот идентификатор можно просто прочитать из текущей записи?

Не_проходи_мимооткрыть в другой области again
У вас проблема в том, что вы пишите приложение не с нуля, а сопровождаете уже готовое решение. Поэтому любая технология, отличная от использования Relation потребует существенной переделки приложения. Слишком много затрат. Проще "вписаться" в существующую идеологию, особенно, если это разовая задача.

Не_проходи_мимоили сделать Cursor Adapter(ведь его источником всё равно является запрос, тогда чем он лучше запроса в конкретном случае не клиент серверной технологии)
Использование запроса лучше, чем Relation в том плане, что проще модифицировать задачу.

Дело в том, что relation накладывает ряд ограничений. Например, недопустимо менять главный индекс подчиненной таблицы. Если пользователь захотел иметь возможность сортировки, то вы просто ничего не сможете сделать. Relation не позволит.

Ну, а почему именно CursorAdapter, а не прямой запрос, так Александр уже объяснил. Над запросом все-равно придется писать некую "обертку" по его обработке. А в CursorAdapter эта "обертка" уже есть.