SQLite v mobilním vývoji: co to je a jak funguje

Co je SQLite?

SQLite je knihovna v jazyce C, která implementuje relační ŘÍP bez vyhrazeného serveru. Je přímo vestavěna do aplikace, čte a zapisuje data do běžného souboru v souborovém systému zařízení. Velikost knihovny je přibližně 600 KB, což činí SQLite nejlehčí plně funkční SQL databází.

SQLite podporuje většinu standardu SQL:1999, včetně JOIN, poddotazů, triggerů, pohledů, indexů a okenních funkcí. Omezení se týkají ALTER TABLE (omezená podpora) a úplného RIGHT/FULL OUTER JOIN. Nicméně pro mobilní aplikace je funkcionalita SQLite dostačující v 99 % případů lokálního ukládání.

Podle průzkumu vývojářů Stack Overflow (2025) je SQLite nejoblíbenější databází pro vestavěná řešení a zaujímá třetí místo v oblíbenosti mezi všemi ŘÍP po MySQL a PostgreSQL. V mobilním vývoji se SQLite používá v každé aplikaci — přímo nebo prostřednictvím obalů.

Klíčové vlastnosti SQLite

Zero-configuration — SQLite nevyžaduje instalaci, nastavení oprávnění, vytváření uživatelů nebo spuštění služby. Knihovna se připojí k projektu a databáze se vytvoří zavoláním jedné funkce. To radikálně zjednodušuje nasazení ve srovnání s ŘÍP klient-server, která vyžadují instalaci serveru, konfiguraci portů a konfiguraci uživatelů.

Soubor databáze SQLite je běžný multiplatformní soubor, který lze zkopírovat, analyzovat, odeslat po síti nebo obnovit ze zálohy. Formát souboru je na úrovni API stabilní: soubory SQLite 3 vytvořené v roce 2004 se otevírají aktuální verzí knihovny, což zaručuje dlouhodobou kompatibilitu dat.

Jak je SQLite strukturováno: architektura a ukládání

Architektura SQLite se skládá z osmi virtuálních strojů: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface a Utilities. SQL dotaz prochází Tokenizerem (rozdělení na tokeny), Parserem (stavba AST), Code Generatorem (převod na bajtový kód) a je proveden na virtuálním stroji, který čte stránky dat prostřednictvím B-Tree a Pageru.

SQLite používá B-Tree pro ukládání tabulek a indexů. Každá tabulka je uložena jako samostatné B-Tree, kde listové uzly obsahují řádky dat. Indexy jsou také uloženy jako B-Tree, ale s klíči v listech. Pager řídí načítání stránek (ve výchozím nastavení 4096 bajtů) ze souboru do paměti, čímž zajišťuje ACID transakce prostřednictvím protokolu nebo WAL.

Režimy protokolování

WAL (Write-Ahead Logging) — doporučený režim pro mobilní aplikace. Změny se nejprve zapíší do samostatného WAL souboru a poté se periodicky přenášejí do hlavní databáze. WAL umožňuje současné čtení z databáze (stará data) a zápis do ní (prostřednictvím WAL), což zvyšuje výkon vícevláknových aplikací. Standardní protokol (rollback journal) blokuje čtení během zápisu.

Přepínání mezi režimy se provádí jedním SQL dotazem: PRAGMA journal_mode=WAL. Pro mobilní aplikace s backendovou synchronizací a vláknem UI, které současně čte data, poskytuje WAL lepší výkon a žádné blokování rozhraní.

SQLite vs ostatní databáze v mobilním vývoji

SQLite není jedinou možností pro lokální ukládání dat, ale je nejuniverzálnější. Realm nabízí vyšší rychlost přímého přístupu k objektům v paměti, ale používá vlastní formát NoSQL a má větší velikost knihovny. Core Data na iOS je ORM vrstva nad SQLite, která přidává správu grafu objektů a vrácení operací.

Pro většinu aplikací zůstává SQLite optimální volbou díky předvídatelnému výkonu, žádné závislosti na dodavateli a časem prověřené stabilitě. Realm a Core Data jsou oprávněné v projektech se složitými grafy objektů, reaktivními dotazy nebo požadavky na synchronizaci mezi zařízeními.

Výběr mezi SQLite, Realm a Core Data závisí na platformě, požadavcích na objektový model a strategii synchronizace. Pro multiplatformní projekty (KMP, Flutter) zůstává SQLite jedinou univerzální volbou, která funguje na všech cílových platformách bez změn modelu dat.

SQLite na Androidu: Room a SQLiteOpenHelper

Room — knihovna z Android Jetpack, která poskytuje ORM vrstvu nad SQLite. Room automaticky generuje SQL dotazy z anotovaných DAO rozhraní, kontroluje správnost dotazů při kompilaci a podporuje migrace databáze při změně schématu. Room je doporučený způsob práce s SQLite na Androidu.

SQLiteOpenHelper — nízkoúrovňové API pro přímou správu SQLite bez ORM. Třída řídí vytváření, otevírání a aktualizaci databáze. SQLiteOpenHelper je vhodný pro projekty s jednoduchými SQL dotazy nebo když je potřeba úplná kontrola nad SQL logikou bez abstrakce Room.

Příklad entity a DAO pro Room

Entita v Room je anotována @Entity a DAO @Dao. Room převádí anotované metody na SQL dotazy: @Insert generuje INSERT, @Query — SELECT s uvedeným SQL. Migrace se přidávají prostřednictvím Migration s uvedením staré a nové verze schématu. Room kontroluje SQL při kompilaci, což eliminuje syntaktické chyby v produkci.

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

Room automaticky generuje implementaci UserDao_Impl, která obsahuje runtime dotazy na SQLite prostřednictvím interního RoomDatabase. Díky korutinám (suspend) jsou DAO metody prováděny asynchronně na backendovém vlákně, aniž by blokovaly UI. Návratové typy Flow v @Query automaticky aktualizují výsledek při změně tabulky.

SQLite na iOS: FMDB a GRDB

FMDB — Objective-C obal nad C API SQLite, historicky první populární knihovna pro iOS. Poskytuje objekty FMDatabase a FMResultSet pro provádění dotazů a získávání výsledků. FMDB je jednoduchá a minimalistická, ale nepodporuje Swift-specifické konstrukce — optionals, Codable, async/await.

GRDB — moderní Swift knihovna pro práci s SQLite. Poskytuje type-safe API, podporu Codable, Combine Publishers, async/await, migrace a sledování změn v reálném čase. GRDB je preferována pro nové projekty ve Swiftu díky plné integraci se Swift Concurrency a lepší čitelnosti kódu.

Příklad GRDB ve Swiftu

GRDB definuje tabulky pomocí Record tříd, které vyhovují protokolům FetchableRecord a TableRecord. Dotazy se píší ve Swiftu s type-safe syntaxí, nikoli v syrovém SQL. GRDB také podporuje DatabaseMigrator pro verzování schématu a migrace mezi verzemi aplikace.

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

DatabasePool používá WAL režim SQLite pro souběžné čtení. Více čtenářů může současně přistupovat k databázi, zatímco jeden zapisovatel aktualizuje data prostřednictvím WAL. GRDB automaticky spravuje připojení a transakce, čímž poskytuje thread-safe přístup k databázi z libovolného vlákna bez ruční synchronizace.

Optimalizace výkonu SQLite

Indexy — nejúčinnější způsob zrychlení SQLite dotazů. Index je vytvořen na sloupcích, které se účastní WHERE, JOIN a ORDER BY. Pro tabulku se 100 000 záznamy trvá vyhledávání podle indexovaného sloupce milisekundy místo sekund. Indexy ale zpomalují INSERT a UPDATE, proto musí být jejich počet vyvážen s frekvencí zápisu.

Dávkový vkládání (batch insert) v rámci jedné transakce radikálně zrychluje hromadné načítání dat. Vložení 1000 záznamů jeden po druhém má režii přibližně 1 sekundu. Stejných 1000 záznamů v jedné transakci — přibližně 5–10 milisekund. Rozdíl je způsoben tím, že každý samostatný INSERT vytváří novou transakci se synchronním zápisem na disk.

PRAGMA výkonu

PRAGMA — příkazy SQLite pro konfiguraci chování knihovny. Klíčové optimalizační PRAGMA: PRAGMA synchronous=NORMAL (snižuje frekvenci fsync), PRAGMA cache_size=-8000 (alokuje 8 MB cache), PRAGMA temp_store=MEMORY (dočasné tabulky v paměti). Pro mobilní aplikace s velkými objemy dat kombinace těchto PRAGMA zrychluje dotazy 2–3krát.

Další důležitou optimalizací je předkompilace SQL dotazů (prepared statements). Pokud se dotaz provádí opakovaně (například vkládání 10 000 řádků), jednorázová kompilace SQL a následné použití statementu snižuje zátěž CPU o 30–50%. Room a GRDB automaticky kešují prepared statements, ale při přímém použití C API SQLite je třeba kompilaci provést ručně.

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

Dávkový vkládání s withTransaction zaručuje, že všechny INSERT jsou provedeny v rámci jedné transakce. Rozdělení na poddávky (chunked) zabraňuje příliš velké transakci, která by mohla blokovat ostatní vlákna na delší dobu. Pro backendovou synchronizaci poskytuje velikost poddávky 500 záznamů optimální rovnováhu mezi rychlostí a odezvou UI.