SQLite vs Realm для offline‑first хранилища в полевых приложениях

Что действительно нужно офлайн‑первым полевым приложениям

Offline‑first — это не просто «работает без интернета». Это значит, что приложение может загрузить полезные данные, принять новый ввод и сохранить каждое изменение до момента синхронизации.

Полевая работа накладывает набор предсказуемых ограничений: сигнал прерывается, сессии длинные, устройства могут быть старыми, режимы энергосбережения включены. Люди работают быстро: открывают задачу, листают длинные списки, фотографируют, заполняют формы и сразу переходят к следующей задаче, не думая о хранении.

Пользователи замечают простое: они теряют доверие, когда правки исчезают, когда списки и поиск тормозят в офлайне, когда приложение не может чётко ответить «мою работу сохранило?», когда записи дублируются или пропадают после подключения, или когда обновление вызывает странное поведение.

Поэтому выбор между SQLite и Realm в основном сводится к повседневному поведению, а не к бенчмаркам.

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

1) Ваши данные будут меняться

Даже «стабильные» приложения эволюционируют: новые поля, переименованные статусы, новые экраны. Если миграции болезненны, вы либо выпускаете меньше улучшений, либо рискуете сломать реальные устройства с реальными данными.

2) Запросы должны соответствовать реальным рабочим процессам

Полевые приложения нуждаются в быстрых фильтрах: «задачи на сегодня», «ближайшие объекты», «несинхронизированные формы», «элементы, отредактированные за последние 2 часа». Если база делает такие запросы неудобными, интерфейс тормозит, а код превращается в лабиринт.

3) Офлайн‑синхронизация создаёт конфликты

Два человека могут редактировать одну запись, или устройство может править устаревшие данные в течение дней. Нужен чёткий план: что выигрывает, что сливается, а что требует вмешательства человека.

4) Инструменты важны

Когда в поле что‑то идёт не так, нужно быстро смотреть данные, воспроизводить проблему и понимать, что произошло, без домыслов.

Миграции: менять модель данных, не ломая пользователей

Полевые приложения редко стоят на месте. Через пару недель вы добавите чекбокс, переименуете статус или разделите поле «notes» на структурированные поля. Миграции — там, где офлайн‑приложения часто терпят неудачу, потому что на телефоне уже есть реальные данные.

SQLite хранит данные в таблицах и столбцах. Realm — как объекты с свойствами. Эта разница проявляется быстро:

• В SQLite обычно пишут явные изменения схемы (ALTER TABLE, новые таблицы, копирование данных).
• В Realm обычно повышают версию схемы и запускают функцию миграции, которая обновляет объекты по мере их доступа.

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

Крупные преобразования на устройствах требуют осторожности. Миграция, переписывающая каждую запись, может быть медленной на старых телефонах, и техника не должна застревать с индикатором загрузки на парковке. Планируйте время миграции и подумайте о разделении тяжёлых трансформаций на несколько релизов.

Чтобы честно тестировать миграции, относитесь к ним как к синхронизации:

• Установите старую сборку, создайте реалистичные данные, затем обновитесь.
• Тестируйте на небольших и больших наборах данных.
• Убейте приложение в середине миграции и перезапустите.
• Тестируйте сценарии с малым свободным местом.
• Предположите, что можно откатиться вперёд, даже если назад — нет.

Пример: если «equipmentId» стал «assetId», а потом разделился на «assetType» и «assetNumber», миграция должна сохранить старые инспекции рабочими, не заставляя пользователей выходить или чистить данные.

Гибкость запросов: что можно спросить у данных

Полевые приложения живут благодаря экранам списков: задачи на сегодня, ближайшие активы, клиенты с открытыми заявками, использованные запчасти за неделю. Выбор хранилища должен позволять задавать такие вопросы легко, быстро и так, чтобы через полгода их было просто поддерживать.

SQLite даёт вам SQL — самый гибкий способ фильтрации и сортировки больших наборов данных. Можно комбинировать условия, делать JOIN, группировки и добавлять индексы, когда экран начинает тормозить. Если нужно «все инспекции для активов в Регионе A, назначенные Команде 3, с любым провалившимся пунктом чеклиста», SQL обычно выражает это чисто.

Realm опирается на объекты и более высокоуровневое API запросов. Для многих приложений это кажется естественным: запросить объекты Job, отфильтровать по статусу, отсортировать по дате, перейти по связям к связанным объектам. Компромисс в том, что некоторые вопросы, тривиальные в SQL (особенно отчётные запросы через множество связей), в Realm могут быть сложнее или потребуют перестройки данных под нужные запросы.

Поиск и связи

Для частичного текстового поиска по нескольким полям (название задачи, имя клиента, адрес) SQLite часто направляет вас к аккуратной индексации или отдельному решению full‑text. Realm тоже умеет фильтровать по тексту, но нужно думать о производительности и смысле операции "contains" при масштабе.

Связи — ещё одна практичная боль. SQLite решает one‑to‑many и many‑to‑many через вспомогательные таблицы, что делает такие паттерны, как «активы с этими двумя тегами», очевидными. Realm‑ссылки удобно обходить в коде, но many‑to‑many и «запрос сквозь связи» обычно требуют планирования, чтобы чтения оставались быстрыми.

Сырые запросы против удобства поддержки

Практичный паттерн для поддержки — держать небольшой набор именованных запросов, которые напрямую соответствуют экранам и отчётам: основные фильтры и сортировки списка, запрос для детального вида (одна запись плюс связанные записи), определение поиска, несколько счётчиков (бейджи и офлайн‑итоги) и экспортные/отчётные запросы.

Если ожидаются частые ad‑hoc запросы от бизнеса, сырая сила SQL тяжело переигрывается. Если же хотите, чтобы доступ к данным читался как работа с обычными объектами, Realm позволит быстрее собрать продукт, пока он отвечает на самые сложные экраны без костылей.

Разрешение конфликтов и синхронизация: какая поддержка есть

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

Конфликты проявляются просто. Техник обновляет инспекцию на планшете в подвале без сигнала. Позже супервайзер правит ту же инспекцию с ноутбука. Когда оба подключатся, сервер получит две версии.

Большинство команд приходят к одному из подходов:

• Last write wins (быстро, но может тихо перезаписать хорошие данные)
• Merge by field (безопаснее, когда меняются разные поля, но нужны чёткие правила)
• Ручная очередь проверки (медленнее, но для критичных изменений лучше)

SQLite даёт надёжную локальную базу, но сам по себе не даёт синхронизации. Обычно вы пишете остальную логику: отслеживание ожидающих операций, отправка на API, безопасные ретраи и применение правил конфликтов на сервере.

Realm может сократить объём «проводки», если вы используете его встроенные возможности синхронизации, потому что он заточен под объекты и отслеживание изменений. Но «встроенная синхронизация» всё равно не решает бизнес‑правила: вы должны указать, что считать конфликтом и какие данные могут выигрывать.

Планируйте аудит‑трейл с самого начала. Полевые команды часто требуют ответы на «кто что изменил, когда и с какого устройства». Даже если выбрали last write wins, сохраняйте метаданные: user ID, device ID, timestamps и (по возможности) причину. Если бэкенд генерируется быстро, например через no‑code платформу AppMaster, проще итеративно настраивать правила до того, как сотни офлайн‑устройств окажутся в продакшене.

Отладка и инспекция: ловить проблемы до того, как до поля дойдут жалобы

Офлайн‑баги тяжело отлавливать, потому что они происходят вне наблюдения сервера. Опыт отладки часто сводится к одному вопросу: насколько легко увидеть, что хранится на устройстве и как это менялось со временем?

SQLite просто инспектировать, потому что это файл. В разработке или QA вы можете вытащить базу с тестового устройства, открыть её стандартными SQLite‑инструментами, запускать ad‑hoc запросы и экспортировать таблицы в CSV или JSON. Это помогает подтвердить «какие строки есть» vs «что показывает UI». Минус — нужно понимать схему, JOINы и любые вспомогательные миграционные слои.

Realm больше похож на «приложение» для инспекции: данные хранятся как объекты, и инструменты Realm часто удобнее для просмотра классов, свойств и связей. Это хорошо для поиска проблем в объектном графе (отсутствующие ссылки, неожиданные null), но ad‑hoc анализ менее гибок, если команда привыкла к SQL‑инструментам.

Логгирование и воспроизведение офлайн‑ошибок

Большинство полевых сбоев сводится к тихим ошибкам записи, частичным пакетам синхронизации или миграции, которая завершилась наполовину. Вложитесь в несколько базовых вещей: метки «последнее изменение» для каждой записи, локальный журнал операций, структурированные логи миграций и фоновых записей, возможность включить подробное логирование в QA‑сборках и действие «дамп и поделиться», которое экспортирует редактированный снимок состояния.

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

Поделиться ошибочным снимком

В случае SQLite часто достаточно поделиться файлом .db (и файлами WAL). У Realm обычно нужно поделиться файлом Realm и его побочными файлами. В обоих случаях прописывайте повторяемый процесс удаления чувствительных данных перед отправкой.

Надёжность в реальном мире: сбои, сбросы и обновления

Полевые приложения падают по «скучным» причинам: батарея садится во время сохранения, ОС убивает приложение на фоне, или хранилище заполняется после недель фотографий и логов. Выбор локальной базы влияет на то, как часто такие сбои превращаются в потерю работы.

При падении во время записи и SQLite, и Realm могут быть безопасны при корректном использовании. SQLite надёжна при обёртывании изменений в транзакции (режим WAL помогает с устойчивостью и производительностью). Записи Realm транзакционны по умолчанию, так что обычно вы получаете «всё или ничего» без лишних усилий. Общая опасность — не движок БД, а код приложения, который пишет в несколько шагов без явной точки подтверждения.

Коррупция встречается редко, но нужен план восстановления. Для SQLite можно запускать integrity‑проверки, восстанавливать из известной резервной копии или перестраивать из синхронизации с сервера. Для Realm при подозрении на повреждение файл Realm может оказаться под вопросом, и практический путь восстановления часто — «удалить локальные данные и пересинхронизировать» (приемлемо, если сервер — источник истины, болезненно, если на устройстве есть уникальные данные).

Рост размера хранилища — ещё один сюрприз. SQLite может раздуться после удалений, если не выполнять VACUUM периодически. Realm тоже может расти и требует политик компактирования и чистки старых объектов (например, завершённых задач), чтобы файл не увеличивался бесконечно.

Обновления и откаты — ещё одна ловушка. Если апдейт меняет схему или формат хранения, откат может оставить пользователей с файлом новой версии, который старый билд не прочитает. Планируйте обновления как однонаправленные: безопасные миграции и опцию «сбросить локальные данные», которая не ломает приложение.

Полезные практики для надёжности:

• Обрабатывайте «полный диск» и ошибки записи с понятным сообщением и путём повторной попытки.
• Сохраняйте ввод пользователя чекпоинтами, а не только в конце длинной формы.
• Держите лёгкий локальный аудит‑журнал для восстановления и поддержки.
• Обрезайте и архивируйте старые записи до того, как база вырастет слишком сильно.
• Тестируйте обновления ОС и убийства приложений на слабых устройствах.

Пример: приложение для инспекций, которое хранит чеклисты и фото, может столкнуться с нехваткой места через месяц. Если приложение заранее определяет низкое место, оно может приостановить съёмку фото, загружать их по возможности и сохранять чеклист без потерь, независимо от выбора локальной базы.

Пошагово: как выбрать и настроить подход к хранению

Рассматривайте хранилище как часть продукта, а не как библиотеку. Лучший вариант — тот, который сохраняет работоспособность приложения при падении сигнала и делает поведение предсказуемым при восстановлении.

Простой путь принятия решения

Сначала пропишите офлайн‑флоу пользователей. Будьте конкретны: «открыть задачи на сегодня, добавить заметки, прикрепить фото, пометить как завершённое, снять подпись». Всё в этом списке должно работать без сети, каждый раз.

Затем пройдите короткую последовательность: выделите критичные офлайн‑экраны и сколько данных им нужно (задачи на сегодня vs полная история), набросайте минимальную модель данных и связи, которые нельзя имитировать (Job -> ChecklistItems -> Answers), выберите правило конфликтов для каждой сущности (не один общий), решите, как тестировать сбои (миграции на реальных устройствах, повторы синхронизации, принудительный выход/переустановка), и соберите небольшой прототип с реалистичными данными, который можно замерить (загрузка, поиск, сохранение, синк после дня офлайна).

Этот процесс обычно выявляет реальное ограничение: нужны ли гибкие ad‑hoc запросы и простая инспекция, или вы цените объектный доступ и жёсткую модель?

Что валидировать в прототипе

Возьмите один реалистичный сценарий, например техник завершает 30 инспекций офлайн, затем едет в зону покрытия. Измерьте время первой загрузки при 5 000 записях, переживёт ли изменение схемы обновление, сколько конфликтов появится после подключения и можно ли объяснить каждый из них, а также как быстро можно исследовать «плохую запись» при звонке в поддержку.

Если хотите быстро проверить флоу до окончательного решения, no‑code прототип в AppMaster поможет зафиксировать рабочий процесс и модель данных до того, как вы выберете локальную базу.

Распространённые ошибки, которые вредят офлайн‑первым приложениям

Большинство провалов не от движка БД, а от пропуска скучных частей: обновлений, правил конфликтов и понятной обработки ошибок.

Одна ловушка — думать, что конфликты редки. В полевой работе это нормально: два техника правят один актив, или супервайзер меняет чеклист, пока устройство офлайн. Без правил (last write wins, merge by field или сохранить обе версии) вы рано или поздно перезапишете реальную работу.

Ещё одна тихая ошибка — считать модель данных «завершённой» и не отрабатывать обновления. Схемы меняются и в маленьких приложениях. Если не версионируете схему и не тестируете обновления со старых сборок, пользователи могут застрять после апдейта с провалившимися миграциями или пустыми экранами.

Проблемы производительности проявляются поздно. Команды иногда скачивают всё «на всякий случай», а потом удивляются, почему поиск медленный и приложение открывается минуты на среднем телефоне.

Паттерны, за которыми нужно следить:

• Отсутствие письменной политики конфликтов → правки затираются молча.
• Миграции, которые работают на чистой установке, но падают на реальных обновлениях.
• Кеширование офлайн, которое растёт без ограничений, делая запросы медленными.
• Сбои синка, скрытые за индикатором загрузки, так что пользователь думает, что данные отправлены.
• Отладка по домыслам вместо повторяемого repro‑скрипта и примерных данных.

Пример: техник завершает инспекцию офлайн, нажимает Sync и не получает подтверждения. Загрузка не удалась из‑за проблемы с токеном авторизации. Если приложение скрывает ошибку, техник уходит, думая, что задача закрыта, и доверие уходит.

Какой бы движок вы ни выбрали, прогоните базовый «полевой режим» тест: режим самолёта, низкий заряд, обновление приложения и два устройства, редактирующие одну запись. Если вы быстро собираете прототип в no‑code вроде AppMaster, включите эти тесты в прототип до того, как рабочий процесс попадёт на большую команду.

Быстрый чеклист перед финальным выбором

Перед окончательным выбором движка опишите, что значит «хорошо» для вашего полевого приложения, и протестируйте это на реальных данных и устройствах. Команды спорят о функциях, но большинство провалов связано с базовыми вещами: обновления, медленные экраны, неясные правила конфликтов и отсутствие способа инспектировать локальное состояние.

Используйте это как критерий go/no‑go:

• Подтвердите обновления: возьмите по крайней мере две старые сборки, обновитесь до текущей и убедитесь, что данные открываются, редактируются и синхронизируются.
• Держите ключевые экраны быстрыми при реальном объёме: загрузите реалистичные данные и замерьте самые медленные экраны на среднем телефоне.
• Опишите политику конфликтов для каждого типа записи: инспекции, подписи, использованные запчасти, комментарии.
• Сделайте локальные данные инспектируемыми и логи собираемыми: опишите, как поддержка и QA снимают состояние в офлайне.
• Спланируйте предсказуемое восстановление: когда перестраивать кеш, перекачивать данные или требовать повторного входа. Не делайте «переустановите приложение» планом.

Если прототипируете в AppMaster, применяйте ту же дисциплину. Тестируйте обновления, определяйте конфликты и репетируйте восстановление до релиза команде, которая не может позволить простоя.

Пример сценария: приложение для инспекций техника при плохом сигнале

Техник начинает день, скачав 50 нарядов. В каждой задаче — адрес, обязательные пункты чеклиста и несколько справочных фото. Потом сигнал пропадает на весь день.

За визит техник многократно правит одни и те же записи: статус задачи (Arrived, In Progress, Done), использованные запчасти, подпись клиента и новые фото. Некоторые правки мелкие и частые (статус), другие — большие (фото) и их нельзя потерять.

Момент синхронизации: двое коснулись одной задачи

В 11:10 техник отмечает Задачу #18 как Done и добавляет подпись офлайн. В 11:40 диспетчер переназначает задачу, потому что в офисе она всё ещё выглядит открытой. Когда техник подключается в 12:05, приложение загружает изменения.

Хороший поток конфликтов не скрывает это. Он показывает это. Супервайзер должен увидеть простое сообщение: «Существуют две версии Задачи #18», с ключевыми полями рядом (статус, назначенный техник, метка времени, подпись да/нет) и понятными опциями: сохранить локальные изменения, сохранить офисные или слить по полям.

Именно здесь выбор хранилища и синка проявляется: можно ли отследить чистую историю изменений и воспроизвести её после долгого офлайна?

Когда задача «исчезает», отладка — это в большинстве случаев доказать, что случилось. Логируйте достаточно, чтобы ответить: локальный ID записи и серверный ID (включая момент создания), каждая запись с меткой времени/пользователем/устройством, попытки синка и сообщения об ошибках, решения по конфликтам и победитель, а также статус загрузки фото, отслеживаемый отдельно от записи задачи.

С такими логами вы воспроизводите проблему, а не догадываетесь по жалобе.

Следующие шаги: быстро валидируйте, затем стройте полное поле решение

Прежде чем ввязываться в споры SQLite vs Realm, напишите одностраничную спецификацию офлайн‑флоу: экраны техника, какие данные живут на устройстве и что должно работать без сети (создать, редактировать, фото, подписи, очередь загрузки).

Затем прототипируйте всю систему рано, а не только базу данных. Полевые приложения ламаются в стыках: мобильная форма, которая сохраняет локально, бесполезна, если админ‑команда не может просмотреть и исправить записи или если бэкенд позже отвергает обновления.

Практический план валидации:

• Соберите тонкий end‑to‑end срез: одна офлайн‑форма, один список, одна попытка синка, один админ‑экран.
• Проведите тест изменений: переименуйте поле, разделите поле на два, выпустите тестовую сборку и посмотрите, как ведёт себя обновление.
• Симулируйте конфликты: редактируйте одну запись на двух устройствах, синхронизируйте в разном порядке и фиксируйте, что ломается.
• Репетируйте отладку в поле: решите, как будете инспектировать локальные данные, логи и неудавшиеся полезные нагрузки на реальном устройстве.
• Опишите политику сброса: когда вы чистите локальный кеш и как пользователи восстанавливаются без потери данных.

Если скорость критична, no‑code подход поможет быстро проверить флоу. AppMaster (appmaster.io) — один из вариантов для быстрой сборки полного решения (бэкенд‑сервисы, веб‑панель админа и мобильные приложения), а затем генерации чистого исходного кода по мере изменения требований.

Выберите следующий шаг валидации, исходя из риска. Если формы меняются еженедельно — сперва тестируйте миграции. Если несколько человек работают с одной задачей — тестируйте конфликты. Если боитесь «работало в офисе», приоритизируйте отладочные сценарии в поле.