Lekce 1 - Úvod do databází ve Swift
Vítám vás u první lekce kurzu o programování databázových aplikací ve Swift. Ukážeme si, jak se v iOS pracuje s Apple frameworkem Core Data a také alternativním řešením v podobě Realm.
K čemu databázi?
Možná vás napadlo, k čemu vlastně potřebujeme nějakou databázi. Data bychom stejně dobře mohli ukládat sami do nějakých textových souborů, binárek, XML nebo něčeho podobného. Určitě by to nějak fungovalo, nebo ne?
RDBMS
Označení databáze je vlastně nepřesné a v odborné literatuře se setkáme s označením RDBMS (Relation DataBase Management System). Česky je to přeloženo jako "systém řízení báze dat", což zní opravdu hrozně a proto budu dále používat označení databázový stroj nebo RDBMS. Databázový stroj není jen úložiště dat. Jedná se o velmi sofistikovaný a odladěný nástroj, který za nás řeší spoustu problémů a zároveň je extrémně jednoduchý k použití. Záznamy nám z databáze totiž budou přicházet jako běžné objekty. A od toho jak jsou data fyzicky uložena nebo vyhledávána budeme plně odstíněni, bude to za nás řešit databáze.
S databázemi se často komunikuje pomocí jazyka SQL, což jsou v podstatě lidsky srozumitelné věty. V tomto případě je ale problém s přenášením dat mezi jazykem aplikace (Swift) a SQL, které žádné objekty nezná. Databázové frameworky pro Apple jsou navržené tak, abychom jazyk SQL vůbec nepotřebovali (pokud SQL neovládáte, nebude vám chybět).
Spolu s ukládáním dat je ale třeba dále řešit mnoho dalších věcí. Asi by nás napadlo např. zabezpečení nebo optimalizace výkonu. RDBMS toho ale dělá ještě mnohem více. Nás bude zajímat zejména spojování několika dotazů do transakcí, kdy se série dotazů vykoná vždy celá nebo vůbec. Nestane se, že by se vykonala jen část. Ačkoli to není vždy úplně snadné, při použití hotové databáze ji můžeme používat z více vláken a spolehnout se, že se nám nepodaří editovat tu samou položku v jeden okamžik a zapříčinit nekonzistenci dat. RDBMS data v tomto případě zamkne a odemkne až po vykonání zápisu. Tyto vlastnosti databázového stroje jsou shrnovány zkratkou ACID, pojďme si ji vysvětlit.
ACID
ACID je akronym slov Atomicity (nedělitelnost), Consistency (konzistentnost), Isolation (izolace) a Durability (trvanlivost). Jednotlivé složky mají následující význam:
- Atomicity - Operace v transakci se provedou jako jedna atomická (nedělitelná) operace. Tzn. že pokud nějaká část operace selže, vrátí se databáze do původního stavu a žádné části transakce nebudou provedeny. Reálný příklad je např. převod peněz na bankovním účtu. Pokud se nepodaří peníze odečíst z jednoho účtu, nebudou ani připsány na účet druhý. Jinak by byla databáze v nekonzistentním stavu. Pokud bychom si práci s daty řešili sami, mohlo by se nám toto velmi jednoduše stát.
- Consistency - Stav databáze po dokončení transakce je vždy konzistentní, tedy validní podle všech definovaných pravidel a omezení. Nikdy nenastane situace, že by se databáze nacházela v nekonzistentním stavu.
- Isolation - Operace jsou izolované a navzájem se neovlivňují. Pokud se sejde v jeden okamžik více dotazů na zápis do stejného objektu, jsou vykonávány postupně, jako ve frontě.
- Durability - Všechna zapsaná data jsou okamžitě zapsána na trvanlivá úložiště (na pevný disk), v případě výpadku el. energie nebo jiného přerušení provozu RDBMS vše zůstane tak, jak bylo těsně před výpadkem.
Databáze (přesněji databázový stroj) je tedy černá skříňka, se kterou naše aplikace komunikuje a do které ukládá veškerá data. Její použití je velmi jednoduché a je odladěna tak, jak bychom si sami zápis dat v programu asi těžko udělali. Vůbec se nemusíme starat o to, jak jsou data fyzicky uložena, s databází komunikujeme pomocí jednoduchého rozhraní. V dnešní době se vůbec nevyplatí zatěžovat se otázkou ukládání dat, jednoduše sáhneme po hotové databázi, kterých je obrovský výběr a jsou většinou zadarmo. O databázi občas hovoříme jako o 3. vrstvě aplikace (1. vrstva je uživatelské rozhraní, 2. vlastní logika aplikace, 3. je právě datová vrstva).
Dostupné databáze na Apple platformách
V Apple světě existují víceméně 3 sofistikované možnosti, jak ukládat data. Když chceme uložit HiScore ve hře, tak se ještě bez databáze obejdeme. Ovšem pro data, která mezi sebou mají nějaké vztahy a ve kterých potřebujeme např. optimalizovaně vyhledávat, je v podstatě nepostradatelná. Naše možnosti jsou:
- Core Data
- Realm
- SQLite
Pojďme si je vysvětlit.
Core Data
Core Data je oficiální Apple framework pro ukládání dat na Apple zařízeních. Není to databáze, to znamená, že jde o rozhraní jakým s daty pracujeme a vnitřně Core Data používá k ukládání dat nějaká další řešení. Můžeme volit mezi:
- XML soubory (není v iOS a je určeno spíše pro debugging, má nízký výkon, ale je lidsky čitelné)
- Binární soubory (stejně jako XML úložiště poskytuje atomické ukládání)
- Databáze SQLite
- Operační paměť (tato možnost není trvalé úložiště, ale umožňuje ukládat objekty se všemi vazbami na všechno)
Vnitřní úložiště lze přepínat (např. v začátku projektu můžeme zvolit pro možnost kontroly co máme uloženo formát XML). Neměli bychom ale např. manipulovat s interní SQL databází Core Data externími nástroji. Core Data se používá na iOS, macOS, watchOS a tvOS. Na iOS, který nás bude zajímat asi nejvíce, je k dispozici od verze 3.0, takže již více než deset let. Jedná se o léta prověřené řešení, které Apple neustále vyvíjí a jde o nejčastější způsob, jak na těchto platformách ukládat větší množství dat.
Interně Core Data pracuje s již zmíněnou SQLite databází a vlastně nad ní poskytuje ucelené rozhraní, přes které s touto databází pracujeme. To má řadu výhod, například nemusíme psát ručně SQL příkazy a parsovat data na objekty jazyka Swift. Navíc, když k databázi budete přistupovat pouze přes Core Data, tak se nemůže stát, že byste mohli poškodit data a tím o ně přijít.
Core Data umí samo sledovat změny objektů a ty následně ukládat. Nabízí robustní možnosti, jak s daty pracovat na pozadí pro náročnější úkony a mimo jiné za vás zvládne vyřešit migrace.
Migrace ve světě Core Data a dalších podobných frameworků znamená nejčastěji, že jsme rozšířili datový model o nové vlastnosti nebo entity, např. jsme uživateli přidali bankovní účet, a potřebujeme na něj převést data, která máme již uložená podle starého modelu, tedy kde bankovní účet uživatelé nemají.
Core Data je v tomto ohledu dost schopné a velmi často migrace zvládne automaticky bez vašeho přičinění. Například nedělá problém přidání/odebrání vlastností, jejich přejmenování, přidání nových entity či indexů. A jelikož je Core Data přímo od Apple, tak je jeho úvodní nastavení docela jednoduché. Nemusíte instalovat žádné externí balíčky a tak podobně.
Realm
Databáze Realm nepatří pouze do Apple světa a nabízí podporu i pro Javu, .NET, JavaScript či dokonce Objective-C. Kromě toho se autoři chlubí více než 2 miliardami stažení, takže se určitě nebudete učit nějakou obskurní technologii. Prosadila se zejména proto, že použití Core Data bylo v začátcích poměrně komplikované. Funguje podobně jako Core Data, ale vnitřně si data ukládá rovnou do objektového grafu namísto jejich mapování do SQLite databáze.
SQLite
SQLite jsme tu již zmínili v souvislosti s Core Data. Máme ovšem možnost ji používat i přímo a ne přes Core Data.
SQLite je tzv. relační databáze. Tento pojem označuje
databázi založenou na tabulkách, nikoli na objektech. Každá tabulka
obsahuje položky jednoho typu. Můžeme mít tedy tabulku
uzivatele, další tabulku clanky a další třeba
komentare.
Databázovou tabulku si můžeme představit třeba jako tabulku v Excelu. Tabulka uzivatele by
mohla vypadat asi takto:
| Jméno | Příjmení | Datum narození | Počet článků |
|---|---|---|---|
| Jan | Novák | 11.3.1984 | 17 |
| Tomáš | Marný | 1.2.1989 | 6 |
| Josef | Nový | 20.12.1972 | 9 |
| Michaela | Slavíková | 14.8.1990 | 1 |
Položky (konkrétně zde uživatele) ukládáme na jednotlivé řádky, sloupce pak označují atributy (vlastnosti, chcete-li), které položky mají. Pokud chceme s relační databází rozumně pracovat, každý řádek v tabulce by měl být opatřený unikátním identifikátorem. U uživatelů by to mohlo být třeba rodné číslo, mnohem častěji se však používají identifikátory umělé a to tak, že uživatele prostě očíslujeme.
Slovo relační označuje vztah (anglicky relation). Ten je mezi tabulkami nebo mezi entitami v jedné tabulce.
Ve své aplikaci tedy můžeme pracovat s databází SQLite přímo. Musíme pak ale řešit jak Swift objekty převedeme na řádky tabulek a naopak, data totiž musíme posílat databázi pomocí jazyka SQL a získáváme je jako řádky. Core Data, který SQLite databázi obaluje, toto řeší za nás a servíruje nám rovnou naše objekty.
Této technologii automatického převádění objektů na řádky se říká ORM (objektově-relační mapování). Realm vnitřně s relační (tabulkovou) databází pak ani nespolupracuje a nemá tedy co převádět.
Technologie máme tedy zmapované.
Core Data vs. Realm
Než se pustíme do tvorby aplikací využívajících databáze, tak si řekneme, jakou zvolit. Možná vás nepřekvapí, že pomyslný "vítěz" je celkem jasný a tím je Apple framework Core Data.
Má to hned několik důležitých důvodů. Jednak se můžeme spolehnout, že bude do budoucna podporovaný. Je tu s námi od iOS 3 a nic nenaznačuje tomu, že by se ho Apple chystal poslat do důchodu. Místo toho ho pořád vylepšuje a aktualizuje. V posledních verzích iOS je nastavení Core Data dost jednoduché, jak sami uvidíte, a Apple třeba přidal i víceméně automatickou iCloud synchronizaci.
A Core Data prostě patří mezi nejpoužívanější řešení, ignorovat ho můžete snad jen v případě, že chcete dělat pouze hobby aplikace a neplánujete kariéru jako iOS vývojáři.
Realm není vůbec špatná technologie a přináší dost revoluční pohled na data a řada věcí je v něm velmi elegantní. Jenže to automaticky znamená, že váš projekt najednou závisí na dost velké externí knihovně a budete ji muset udržovat aktuální.
Realm bych doporučil zkusit, jestliže už máte Core Data zmáknuté a chcete si rozšířit obzory vyzkoušením alternativního řešení.
V příští lekci, Vytvoření ToDo aplikace (úkolníčku) pro iOS s ukládáním dat, vytvoříme základ ToDo aplikace, na které si dále ukážeme různé možnosti uložení dat.
