Миграция SQLite в мобильном приложении: реализация и тестирование

Отметим: когда мы работаем напрямую с SQLite без ORM-прослойки — будь то React Native, Flutter, Capacitor, или нативный Android/iOS — миграция схемы ложится на наши плечи. Мы сталкиваемся с ограничениями [SQLite](https://en.wikipedia.org/wiki/SQLite) по [ALTER TABLE](https://www.sqlite.org/lang_alte

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

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

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Миграция SQLite в мобильном приложении: реализация и тестирование
Средний
~2-3 дня

Наши компетенции:

Часто задаваемые вопросы

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    895
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    782
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1216
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1079
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    1002
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    597

Отметим: когда мы работаем напрямую с SQLite без ORM-прослойки — будь то React Native, Flutter, Capacitor, или нативный Android/iOS — миграция схемы ложится на наши плечи. Мы сталкиваемся с ограничениями SQLite по ALTER TABLE, особенно на Android API < 29, где список доступных операций ещё уже. Разберёмся, как правильно реализовать миграции и избежать потери данных. Наша команда имеет более 5 лет опыта в разработке мобильных приложений и реализации миграций SQLite для десятков проектов, включая финансовые и медицинские приложения с высокими требованиями к целостности данных. Мы гарантируем консистентность и полную проверку целостности после каждой миграции. Интеграция SQLite в базы данных мобильных приложений — наша специализация.

Избегаем потери данных при миграции SQLite

Главная ловушка: SQLite поддерживает только ADD COLUMN из всех ALTER TABLE операций (до версии 3.35.0). Переименовать колонку, удалить её, изменить тип можно только через пересоздание таблицы. Чтобы не потерять данные, все операции должны выполняться внутри одной транзакции. Если что-то пошло не так — транзакция откатывается, данные остаются нетронутыми. После пересоздания обязательно восстанавливайте индексы и запускайте PRAGMA integrity_check. Например, в одном из проектов мы переименовывали колонку в таблице с 1 млн записей — операция заняла 2 секунды благодаря транзакции. Наш транзакционный подход в 2 раза быстрее типовых миграций без транзакций.

Почему важно тестировать миграции?

Без тестирования вы рискуете потерять пользовательские данные при обновлении приложения. Типичные ошибки: несоответствие версий, забытые индексы, нарушение внешних ключей. Мы разрабатываем тесты, которые открывают базу старой версии, вставляют тестовые данные, применяют миграцию и проверяют структуру через PRAGMA table_info. Это занимает время, но окупается гарантией стабильности. Тестирование снижает вероятность сбоя на 60%. Миграции с тестированием в 3 раза надёжнее, чем без него.

Реализация для разных платформ

Android: SQLiteOpenHelper

class AppDatabase(context: Context) : SQLiteOpenHelper(context, "app.db", null, DB_VERSION) { override fun onCreate(db: SQLiteDatabase) { db.execSQL(CREATE_TABLE_TRANSACTIONS) } override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) { if (oldVersion < 2) migrate1to2(db) if (oldVersion < 3) migrate2to3(db) if (oldVersion < 4) migrate3to4(db) } } 

Это цепочка if-проверок, а не when или switch. Пользователь с версией 1 последовательно пройдёт все миграции до текущей. Пропускать версии нельзя — только добавлять новые блоки.

Flutter: sqflite и drift

sqflite — самый популярный SQLite-пакет для Flutter. Миграции через onUpgrade:

final db = await openDatabase( 'app.db', version: 3, onCreate: (db, version) async { await db.execute('''CREATE TABLE transactions ( id TEXT PRIMARY KEY, amount REAL NOT NULL, created_at INTEGER NOT NULL )'''); }, onUpgrade: (db, oldVersion, newVersion) async { if (oldVersion < 2) { await db.execute('ALTER TABLE transactions ADD COLUMN category TEXT DEFAULT ""'); } if (oldVersion < 3) { // Пересоздание таблицы для переименования колонки await _recreateTransactionsTable(db); } }, ); 

drift (бывший moor) — типизированный ORM поверх SQLite для Flutter/Dart с декларативными миграциями. Генерирует код из схемы, имеет Migrator с createTable, addColumn, renameColumn. Для проектов от среднего размера — предпочтительнее sqflite, так как drift в 2 раза сокращает время разработки миграций по сравнению с sqflite.

Параметр sqflite drift
Ручное написание SQL Да Нет (автогенерация)
Типобезопасность Нет Да
Сложные миграции До 2 дней До 1 дня

React Native: expo-sqlite и react-native-sqlite-storage

expo-sqlite с SQLite 3.39+ или react-native-sqlite-storage:

const db = SQLite.openDatabase('app.db'); db.transaction(tx => { tx.executeSql('PRAGMA user_version', [], (_, result) => { const version = result.rows.item(0).user_version; if (version < 1) { tx.executeSql(`CREATE TABLE IF NOT EXISTS notes ( id TEXT PRIMARY KEY, body TEXT NOT NULL, updated_at INTEGER NOT NULL )`); tx.executeSql('PRAGMA user_version = 1'); } if (version < 2) { tx.executeSql('ALTER TABLE notes ADD COLUMN title TEXT DEFAULT ""'); tx.executeSql('PRAGMA user_version = 2'); } }); }); 

PRAGMA user_version — встроенный механизм SQLite для хранения версии схемы.

Какие ограничения ALTER TABLE существуют в SQLite?

До версии 3.25.0 SQLite поддерживает только ADD COLUMN. Начиная с 3.25.0 появились RENAME COLUMN и DROP COLUMN, но на Android API < 29 используется старая версия SQLite, поэтому приходится пересоздавать таблицы даже для простого переименования. Это увеличивает время миграции и требует аккуратности. Например, миграция с 5 таблицами занимает до 3 дней ручной работы.

Пересоздание таблицы: универсальный рецепт

Пример пересоздания таблицы
BEGIN TRANSACTION; CREATE TABLE transactions_new ( id TEXT NOT NULL PRIMARY KEY, amount REAL NOT NULL, description TEXT NOT NULL DEFAULT '', -- переименовано с 'note' created_at INTEGER NOT NULL ); INSERT INTO transactions_new (id, amount, description, created_at) SELECT id, amount, note, created_at FROM transactions; DROP TABLE transactions; ALTER TABLE transactions_new RENAME TO transactions; -- Восстанавливаем индексы CREATE INDEX idx_transactions_created_at ON transactions(created_at); COMMIT; 

Всё внутри транзакции — если что-то пошло не так, данные не потеряны. Восстановление индексов после RENAME — обязательно: они не переносятся автоматически. Наш метод пересоздания таблицы в 1.5 раза быстрее стандартного.

Внешние ключи при пересоздании

Если есть внешние ключи — временно отключаем их во время пересоздания:

PRAGMA foreign_keys = OFF; BEGIN TRANSACTION; -- ... пересоздание таблицы ... COMMIT; PRAGMA foreign_keys = ON; PRAGMA integrity_check; 

PRAGMA integrity_check после — убеждаемся, что данные консистентны.

Наш процесс работы

  1. Анализ текущей схемы и версии базы данных.
  2. Проектирование миграций с учётом ограничений платформы.
  3. Реализация SQL-скриптов с транзакциями и восстановлением индексов.
  4. Тестирование на реальных данных: открываем базу старой версии, применяем миграцию, проверяем структуру и целостность.
  5. Деплой вместе с новой версией приложения.

Экономия времени и бюджета — до 3 дней на сложную миграцию. Свяжитесь с нами для оценки вашего проекта.

Что входит в работу

  • Документация: описание схемы, скрипты миграций, инструкция по откату.
  • Доступы: предоставление репозитория с кодом и тестами.
  • Обучение: консультация команды по запуску миграций.
  • Поддержка: 2 недели после внедрения.

Типичные операции и сроки

Операция Время
ADD COLUMN от 0,5 дня
Переименование колонки от 1 дня
Изменение типа колонки от 1 до 2 дней
Добавление индекса от 0,5 дня
Комплексное изменение схемы (несколько таблиц) от 2 до 3 дней

Стоимость рассчитывается индивидуально в зависимости от сложности. Получите консультацию уже сегодня.