Настройка SQLite базы данных в мобильном приложении

Настройка SQLite базы данных в мобильном приложении

SQLite встроен в iOS и Android на уровне ОС. Вопрос не в том, подключить ли его — он уже есть. Вопрос в том, как с ним работать так, чтобы через полгода не переписывать всё с нуля из-за запутанных raw-запросов или падений с SQLiteDatabaseLockedException на Android.

Выбор ORM/абстракции

Работать с SQLite напрямую через android.database.sqlite.SQLiteDatabase или sqlite3 на iOS — вариант для минимальных сценариев. В реальных проектах используют ORM:

Room — стандарт для Android, за него голосует Google. GRDB.swift на iOS даёт типобезопасные запросы без лишней магии. SQLDelight интересен для KMM-проектов: один .sq файл с SQL, генерирует Kotlin и Swift код.

Room на Android: правильная архитектура

@Entity(tableName = "products",
    indices = [Index(value = ["category_id"]), Index(value = ["sku"], unique = true)]
)
data class ProductEntity(
    @PrimaryKey val id: String,
    @ColumnInfo(name = "category_id") val categoryId: String,
    val sku: String,
    val title: String,
    @ColumnInfo(name = "price_cents") val priceCents: Int,
    @ColumnInfo(name = "updated_at") val updatedAt: Long,
    @ColumnInfo(name = "is_deleted") val isDeleted: Boolean = false
)

@Dao
interface ProductDao {
    @Query("SELECT * FROM products WHERE category_id = :categoryId AND is_deleted = 0 ORDER BY title ASC")
    fun observeByCategory(categoryId: String): Flow<List<ProductEntity>>

    @Upsert
    suspend fun upsert(products: List<ProductEntity>)

    @Query("UPDATE products SET is_deleted = 1, updated_at = :timestamp WHERE id = :id")
    suspend fun softDelete(id: String, timestamp: Long)
}

@Upsert появился в Room 2.5 — до этого нужно было @Insert(onConflict = OnConflictStrategy.REPLACE). Soft delete через флаг is_deleted — стандартная практика для синхронизируемых баз, чтобы не потерять запись до подтверждения удаления с сервера.

Миграции — самое болезненное место

Room проверяет exportedSchema при изменении схемы. Если fallbackToDestructiveMigration() — база пересоздаётся при каждом изменении схемы. Это нормально для debug, недопустимо для production.

val db = Room.databaseBuilder(context, AppDatabase::class.java, "app.db")
    .addMigrations(MIGRATION_1_2, MIGRATION_2_3)
    .build()

val MIGRATION_2_3 = object : Migration(2, 3) {
    override fun migrate(db: SupportSQLiteDatabase) {
        db.execSQL("ALTER TABLE products ADD COLUMN tags TEXT NOT NULL DEFAULT ''")
        db.execSQL("CREATE INDEX IF NOT EXISTS index_products_updated_at ON products(updated_at)")
    }
}

Экспортируйте схему в JSON (room.schemaLocation в build.gradle) и храните в git. При code review сразу видно, что изменилось в схеме. Room может автоматически сгенерировать миграцию через AutoMigration для простых случаев (добавление колонки), но переименование таблиц и колонок требует @RenameTable/@RenameColumn аннотаций.

GRDB.swift на iOS

// Открытие и настройка
let dbQueue = try DatabaseQueue(path: dbPath)

try dbQueue.write { db in
    try db.create(table: "products", ifNotExists: true) { t in
        t.primaryKey("id", .text)
        t.column("category_id", .text).notNull().indexed()
        t.column("sku", .text).unique()
        t.column("title", .text).notNull()
        t.column("price_cents", .integer).notNull()
        t.column("updated_at", .integer).notNull()
    }
}

// Реактивное наблюдение через ValueObservation
let observation = ValueObservation.tracking { db in
    try Product.filter(Column("categoryId") == categoryId).fetchAll(db)
}
let cancellable = observation.start(in: dbQueue,
    onError: { error in print(error) },
    onChange: { products in self.updateUI(products) }
)

ValueObservation — аналог Room's Flow: автоматически перезапускает запрос при изменении затронутых таблиц.

WAL-режим и производительность

По умолчанию SQLite работает в journal mode. Для мобильных приложений WAL (Write-Ahead Logging) лучше: читатели не блокируют писателей. Room включает WAL автоматически. В GRDB: dbQueue.configuration.journalMode = .wal.

Типичная проблема — N+1 запрос в RecyclerView. SELECT * FROM orders возвращает 200 строк, потом для каждой SELECT * FROM order_items WHERE order_id = ?. 200 запросов в UI thread — ANR через 5 секунд на реальном устройстве. Решение: JOIN или отдельный batch-запрос WHERE order_id IN (...).

Настройка SQLite с Room или GRDB, миграционная стратегия, индексы: 1 неделя на одну платформу. Стоимость рассчитывается индивидуально.