Какую базу данных выбрать для хранения сложных и связанных данных на устройстве

Что проверяют

Знаете ли вы стандартный инструмент для локального реляционного хранения и умеете ли моделировать связи, миграции и реактивное чтение. Следом обычно просят показать, как в Room описывается связь «многие ко многим» и как вы переживаете изменение схемы.

Как отвечать

Для сложных связанных данных ответ по умолчанию это Room поверх SQLite. Реляционная модель как раз придумана для связей, а Room добавляет проверку SQL при компиляции и интеграцию с корутинами. Покажите детали:

• связи: @Relation вместе с @Embedded для «один ко многим», @Junction с таблицей связи для «многие ко многим». Запрос с отношениями помечается @Transaction, чтобы родитель и дети читались согласованно;
• целостность: @ForeignKey с onDelete = CASCADE и индекс на колонке внешнего ключа, иначе каскадное удаление сканирует таблицу. Room предупредит об этом при сборке;
• реактивность: DAO возвращает Flow, и экран обновляется сам после записи в затронутые таблицы;
• миграции: объекты Migration или AutoMigration, экспорт схемы через exportSchema и тесты с MigrationTestHelper;
• потоки: suspend-методы DAO, запросы с главного потока Room по умолчанию запрещает.

Альтернативы называйте с условиями. SQLDelight подходит, если хотите писать SQL первым и делить код с iOS через Kotlin Multiplatform, хотя Room теперь тоже поддерживает KMP. ObjectBox даёт объектную модель без SQL. DataStore годится только для настроек, связей в нём нет.

Где спотыкаются

Советуют Realm как современный выбор. MongoDB объявила свои мобильные SDK на базе Realm устаревшими, поддержка от вендора закончилась в 2025 году, так что для нового проекта это риск.

Оставляют fallbackToDestructiveMigration() в релизе. При первом же изменении схемы пользователи теряют все локальные данные.

Грузят связанные записи в цикле, по запросу на каждого родителя, вместо @Relation или JOIN. На сотне записей это сотня запросов и заметная задержка экрана.