Правильней работать с SQLite через ContentProvider, в которых отсутствует ошибка табличного блокирования

Внимательно прочитай
https://www.sqlite.org/isolation.html
и изучи как это реализовано в различных ORM, если не хочется поймать table lock exception с последующей недоступностью БД
кстати про чтение в Listview/RecyclerView результатов длинных запросов (пример: 200 тыс записей в результате запроса БД в 500Мб на мобиле) тоже много подводных камней и не все описаны

Нижеописанное имеет отношение к работе только с большими БД
(размер >100Мб на мобильном устройстве, кол-ве таблиц свыше 50 и т.д.).
С БД в 2 Мб и 10 табличками можно и нужно работать с ORM.

Все взято из работы над проектом Handifox
аналога 1С уже на мобильном устройстве только с поддержкой режима Offline БД на мобиле
и синхронизацией с десктопной БД в режиме Online

1. Проектируются сущности(таблицы + индексы)
2. Проектируются View - как основной инструмент для выборки данных.
Во View включают только те столбцы, которые используются в табличном просмотре(т.е. 4-6 столбцов).
Таблицы во View связаны строго по индексам
3. Все ListView/RecycleView завязаны на View
4. Для чтения данных используется технология скользящего окна, которое включает максимально
100 записей из View (все оставшиеся записи выталкиваются)
5. При позиционировании на какую то запись и проваливании внутрь
(просмотр и редактирование данных сущности) - создается буфер данных
на 5 записей (2 снизу и 2 сверху), который заполняется автоматом и содержит уже все данные
сущностей - время чтения не более 50 мс
6. Все адаптеры курсорного типа. Запрещено вызывать функцию getCount у курсора, которая тупо
фетчит последовательно все записи. Вместо этого возвращается номер прочитанной записи с макс
позицией в курсоре
7. Пример произвести поиск по наименованию который генерит запрос типа
Select * from Product where name like '*abc*'
запрос абсолютно не попадающий ни в какой индекс и выполняется БД тупо перебором строк
Алгоритм - поиск курсором ведется во View с макс меньшим кол-вом столбцов
и записи отображаются на экране (при этом для операции поиска читается максимально 5-10 строк за раз
(в зависимости от тяжести запроса) - а в обычном пролистывании по 50-100 строк за раз - время не более 80 мс)
8. При пролистывании - за 50 строк до конца списка - посылается запрос на фоновое чтение очередной порции
данных - при этом обновляется счетчик позиции последней прочитанной записи
9. При быстрых переходах 800->200 строку быстрее перейти на 1 строку а уже с нее на 200 чем бросить
запрос курсору тупо перейти на 200 запись
10. Все ORM SQLite работают в режиме для каждого запроса новое соединение,
чтобы не получить table lock
11. Для сильносвязанных сущностей (содержащих данные в 4 и более таблицах) использование
ORM не оправдано - кто работал с 1С знает как работать с ней из коробки и к чему это приводит
12. Обновление сильносвязанных сущностей в ORM выливается в полный гемор из-за того что
в этом участвуют все таблицы сущности и при этом сообщение об обновлении получат все таблицы
участвующие в сущности
13. Поэтому использование ContentProvider поверх View и Tables БД более оправдано
на больщих и сильносвязанных БД

В ORM (Например ORMLite) при обновлении сущности (даже единственной записи в любой таблице) должны генериться
сигнал в Observer по всем таблицам входящих в сущность. Это правильно.
Вы просто не имеете право не получать их - или это неправильная ORM.
Т.е. вы получаете сигнал обновление связанной таблицы->сигнал обновление корневой
таблицы->сигнал обновление всех оставшихся связанных таблиц.
Стандартная технология 1С - когда при смене данных записи в одной связанной таблице приводит к обновлению
всех таблиц входящих в сущность.
Как и в 1С вы просто тонете в в асинхронной перевыборке одних и тех же данных.
В ContentProvider вы можете менять данные локально не задевая сущности и получать сигнал
в единственном Observer связанном с View.

Едиственно разными могут быть технологии обновления - через Update
либо Delete, затем Insert

Алгоритм обновления сущности в классической ORM (аналогично
принятая в 1С)
- удаление всех записей из связанных таблиц
- обновление данных в корневой таблице
- вставка новых данных в связанные таблицы

Алгоритм обновления через ContentProvider:
- обновление данных в связанной таблице
- обновление данных в корневой таблице (поле дата последнего изменения и
вычисляемые поля по изменяемой таблице)
- сигнал в Observer идет только по корневой таблице сущности и изменяемой связанной таблице

Еще раз напоминая , что указанное относится только к сущностям с большим количеством листьев
(не менее 20). Использование ORM дает выгоду только на сущностях с малым кол-вом листьев
- т.е. на объектных БД. SQLite не относиться к объектным БД.

Есть еще одна особенность, которая касается SQLite - в ней используется табличная блокировка при обновлении, поэтому при обновлении сущности через ORM вы получаете блокировку всех таблиц в сущности на продолжительное время.
И при расчетах по спискам сущностей вы получаете жуткие блокировки.
Т.е. вы получаете полный аналог 1с 6.0 при расчетах , когда на одном компе
запускается расчет - все остальные нервно курят

При одном соединении к БД вероятность залететь на Exception по табличной блокировке 100%. Она сопровождается переводом БД в нерабочее состояние. При использовании ORM или ContentProvider обязанность по созданию нового соединения при каждом запросе лежит на них. Если разрабатываешь что-то сам - то обязан сам на Select запросах создавать новое соединение на read БД, на запросах на изменение данных - на каждый запрос новое соединение на Write БД. Или держать одно соединение на read БД, и создавать каждый раз новое соединение на write БД. Можно и так. На ContentProvider тебе вообще ни о чем думать не надо. Единственно при старте приложения единственный раз обратиться к ContenProvider за выборкой из любой таблицы - чтобы БД создалась.