Porovnání SQL, tvůrců dotazů a ORM

Úvod

Použití databáze ke správě dat vaší aplikace je jednou z nejběžnějších voleb pro perzistenci dat. Databáze umožňují rychlé ukládání a vyhledávání informací, poskytují záruky integrity dat a nabízejí perzistenci po dobu životnosti jednotlivé instance aplikace. K dispozici je nespočet typů databází, které splňují požadavky vašeho projektu a vaše preference.

Přímá práce s databázemi z vaší aplikace však není vždy jednoduchá. Rozdíly ve způsobu reprezentace datových struktur často vedou k problémům. Problémy mohou také způsobit potíže při vyjadřování jemností o vztazích mezi různými entitami. K vyřešení tohoto problému bylo vytvořeno mnoho různých nástrojů, které pomáhají fungovat jako rozhraní mezi základní aplikací a datovou vrstvou.

V této příručce se podíváme na některé rozdíly, které vznikají mezi třemi běžnými přístupy:nezpracovaným SQL, tvůrci dotazů a ORM (objektově relační mapovače). Porovnáme některé výhody a nevýhody každého přístupu a poté zakončíme slovníčkem běžně používaných výrazů, který vám pomůže seznámit se s některými klíčovými pojmy.

Jako zjednodušené shrnutí je zde obecný pohled na silné a slabé stránky každého přístupu:

Správa dat pomocí nezpracovaného SQL nebo jiného databázového nativního dotazovacího jazyka

Některé aplikace komunikují přímo s databází psaním a spouštěním dotazů pomocí nativního jazyka podporovaného databázovým strojem. K připojení, ověření a komunikaci s instancí databáze často stačí pouze ovladač databáze.

Vývojáři mohou prostřednictvím připojení odesílat dotazy napsané v rodném jazyce databáze. Na oplátku bude databáze poskytovat výsledky dotazu, rovněž v jednom ze svých nativních formátů. Pro mnoho relačních databází je jazykem dotazování SQL.

Většina relačních databází, stejně jako některé nerelační databáze, podporují strukturovaný dotazovací jazyk, známý také jako SQL, pro vytváření a provádění výkonných dotazů. SQL se ke správě dat používá od 70. let, takže je dobře podporován a do určité míry standardizován.

Výhody nativního dotazování

Použití SQL nebo jiného databázového nativního jazyka má některé jasné výhody.

Jednou z výhod je, že vývojáři píší a spravují databázové dotazy a zpracovávají výsledky explicitně. I když to může být hodně práce navíc, znamená to, že existuje jen málo překvapení, pokud jde o to, co databáze ukládá, jak představuje vaše data a jak tato data dodá, když je později načtete. Nedostatek abstrakce znamená, že existuje méně „pohyblivých částí“, které mohou vést k nejistotě.

Jedním z příkladů je výkon. Zatímco sofistikované abstraktní vrstvy generují dotazy SQL překladem programovacích příkazů, generované SQL může být velmi neefektivní. Zbytečné klauzule, příliš široké dotazy a další nehody mohou vést k pomalým operacím databáze, které mohou být křehké a obtížně se ladí. Nativním psaním v SQL můžete využít všechny své znalosti domény a zdravý rozum, abyste se vyhnuli mnoha třídám problémů s dotazováním

Dalším důvodem, proč používat databázové nativní dotazování, je flexibilita. Žádná abstrakce pravděpodobně nebude schopna být tak flexibilní jako nativní databázový dotazovací jazyk. Vyšší úrovně abstrakce se pokoušejí překlenout propast mezi dvěma různými paradigmaty, což může omezit typy operací, které mohou vyjadřovat. Při psaní v nezpracovaném SQL však můžete využít všech funkcí svého databázového stroje a vyjádřit složitější dotazy.

Nevýhody nativního dotazování

Zatímco nativní dotazování má určité silné stránky, není bez problémů.

Při interakci s databází z aplikace pomocí prostého SQL musíte rozumět základní datové struktuře, abyste mohli sestavit platné dotazy. Jste plně odpovědní za překlad mezi datovými typy a strukturami, které vaše aplikace používá, a konstrukcemi dostupnými v databázovém systému.

Další věc, kterou je třeba mít na paměti při práci s nezpracovaným SQL, je, že je zcela na vás, abyste spravovali bezpečnost svého vstupu. To platí zejména v případě, že ukládáte data poskytnutá externími uživateli, kde by speciálně vytvořený vstup mohl přimět vaši databázi k odhalení informací, které jste nechtěli povolit.

Tento typ zneužití se nazývá SQL injection a představuje potenciální problém, kdykoli může vstup uživatele ovlivnit stav databáze. Vyšší nástroje abstrakce často automaticky dezinfikují uživatelské vstupy, což vám pomůže vyhnout se této třídě problémů.

Práce s nativními dotazovacími jazyky téměř vždy znamená skládání dotazů s běžnými řetězci. To může být bolestivý proces v případech, kdy musíte uniknout vstupu a zřetězit řetězce dohromady, abyste vytvořili platný dotaz. Vaše databázové operace se mohou zabalit do mnoha vrstev manipulace s řetězci, která má vysoký potenciál náhodně zmanipulovat data.

Přehled nativního dotazování

I když jsme v této části hovořili především o SQL, většina zde uvedených informací platí stejně dobře pro jakýkoli nativní databázový dotazovací jazyk. Abych to shrnul, nezpracovaný SQL nebo přímé použití jakéhokoli ekvivalentního dotazovacího jazyka vás dostane nejblíže k abstrakcím používaným databází k ukládání a správě dat, ale nutí vás dělat veškerou těžkou práci ruční správy dat.

Správa dat pomocí nástrojů pro tvorbu dotazů

Alternativním přístupem k používání databázových nativních dotazovacích jazyků, jako je SQL, je použít nástroj nebo knihovnu zvanou tvůrce dotazů pro komunikaci s vaší databází.

Co jsou nástroje pro tvorbu dotazů SQL?

Tvůrce dotazů SQL přidává vrstvu abstrakce nad nezpracované databázové nativní dotazovací jazyky. Dělají to formalizací vzorců dotazování a poskytováním metod nebo funkcí, které přidávají sanitaci vstupu a automaticky udělují položky pro snazší integraci do aplikací.

Struktury a akce podporované databázovou vrstvou jsou stále poměrně dobře rozpoznatelné při použití tvůrců dotazů SQL. To vám umožní pracovat s daty programově a přitom zůstat relativně blízko datům.

Tvůrci dotazů obvykle poskytují rozhraní, které používá metody nebo funkce k přidání podmínky do dotazu. Zřetězením metod dohromady mohou vývojáři skládat kompletní databázové dotazy z těchto jednotlivých "klauzulí".

Výhody tvůrců dotazů SQL

Vzhledem k tomu, že tvůrci dotazů používají stejné konstrukce (metody nebo funkce) jako zbytek vaší aplikace, vývojáři je často považují za snazší spravovat je z dlouhodobého hlediska než nezpracované databázové dotazy zapsané jako řetězce. Je snadné rozpoznat rozdíl mezi operátory a daty a je snadné rozložit dotazy na logické části, které zpracovávají konkrétní části dotazu.

Pro některé vývojáře je další výhodou použití nástroje pro tvorbu dotazů SQL to, že ne vždy skryje základní dotazovací jazyk. Ačkoli operace mohou používat metody místo řetězců, mohou být poměrně transparentní, což usnadňuje těm, kteří jsou obeznámeni s databází, pochopit, co operace udělá. Při použití vyšších úrovní abstrakce to není vždy případ.

Tvůrci dotazů SQL často také podporují více datových backendů, například abstrahují některé jemné rozdíly v různých relačních databázích. To vám umožní používat stejné nástroje pro projekty, které používají různé databáze. Může to dokonce trochu usnadnit migraci do nové databáze.

Nevýhody tvůrců dotazů SQL

Tvůrci dotazů SQL trpí několika stejnými nevýhodami jako nativní dotazovací jazyky.

Jednou z populárních kritik je, že tvůrci dotazů SQL stále vyžadují, abyste rozuměli strukturám a schopnostem databáze a zohledňovali je. Pro některé vývojáře to není dostatečně užitečná abstrakce. To znamená, že kromě specifické syntaxe a schopností samotného tvůrce dotazů musíte mít poměrně dobré znalosti SQL.

Navíc tvůrci dotazů SQL stále vyžadují, abyste definovali, jak načtená data souvisí s daty vaší aplikace. Mezi vašimi objekty v paměti a objekty v databázi není žádná automatická synchronizace.

Zatímco tvůrci dotazů často emulují dotazovací jazyk, se kterým jsou navrženi, další vrstva abstrakce může znamenat, že někdy některé operace nejsou možné pomocí poskytnutých metod. Obvykle existuje „raw“ režim pro odesílání dotazů přímo do backendu, čímž se obchází typické rozhraní tvůrce dotazů, ale tím se problém spíše obchází, než aby se vyřešil.

Přehled nástrojů pro tvorbu dotazů SQL

Celkově lze říci, že tvůrci dotazů SQL nabízejí tenkou vrstvu abstrakce, která se konkrétně zaměřuje na některé z hlavních bolestivých bodů přímé práce s databázovými nativními jazyky. Tvůrci dotazů SQL téměř fungují jako šablonovací systém pro dotazování, což umožňuje vývojářům projít linii mezi přímou prací s databází a přidáváním dalších vrstev abstrakce.

Správa dat pomocí ORM

O krok dále v hierarchii abstrakce jsou ORM. ORM obecně usilují o úplnější abstrakci s nadějí na plynulejší integraci s daty aplikace.

Co jsou ORM?

Objektově relační mapovače nebo ORM jsou části softwaru určené k překladu mezi reprezentacemi dat v relačních databázích a reprezentací v paměti používané s objektově orientovaným programováním (OOP). ORM poskytuje objektově orientované rozhraní pro data v databázi, snaží se použít známé programovací koncepty a snížit množství standardního kódu nutného pro urychlení vývoje.

Obecně platí, že ORM slouží jako abstraktní vrstva, která má vývojářům pomoci pracovat s databázemi, aniž by drasticky měnily objektově orientované paradigma. To může být užitečné tím, že se sníží mentální zátěž spojená s přizpůsobením se specifikům formátu úložiště databáze.

Zejména objekty v objektově orientovaném programování mají tendenci kódovat v sobě mnoho stavu a mohou mít složité vztahy s jinými objekty prostřednictvím dědičnosti a dalších konceptů OOP. Spolehlivé mapování těchto informací do tabulkově orientovaného relačního paradigmatu často není přímočaré a může vyžadovat dobré pochopení obou systémů. ORM se pokoušejí tuto zátěž ulehčit automatizací některých z těchto mapování a poskytováním výrazných rozhraní pro data v systému.

Jsou problémy ORM specifické pro objektově orientované programování a relační databáze?

Podle definice jsou ORM speciálně navrženy pro rozhraní mezi objektově orientovanými aplikačními jazyky a relačními databázemi. Nicméně pokus o mapování a překlad mezi abstrakcemi datové struktury používanými v programovacích jazycích a těmi, které používají databázová úložiště, je obecnějším problémem, který může nastat, kdykoli abstrakce nejsou čistě zarovnány.

V závislosti na programovacím paradigmatu (objektově orientované, funkční, procedurální atd.) a typu databáze (relační, dokument, klíč-hodnota atd.) může být užitečné různé množství abstrakce. Složitost datových struktur v aplikaci často určuje, jak snadné je propojení s úložištěm dat.

Objektově orientované programování má tendenci vytvářet mnoho struktur s významným stavem a vztahy, se kterými je třeba počítat. Některá další programovací paradigmata jsou explicitnější o tom, kde je stav uložen a jak je spravován. Například čistě funkcionální jazyky neumožňují měnitelný stav, takže stav je často vstupem pro funkce nebo objekty, které vydávají nový stav. Toto čisté oddělení dat od akcí a také jednoznačnost životních cyklů stavu může pomoci zjednodušit interakci s databází.

V každém případě je často dostupná možnost propojení s databází prostřednictvím softwaru, který mapuje dvě různé reprezentace. Takže zatímco ORM popisují jejich specifickou podmnožinu s jedinečnými problémy, mapování mezi aplikační pamětí a trvalým úložištěm často vyžaduje zvážení bez ohledu na detaily.

Aktivní záznam vs. ORM mapovače dat

Různé ORM využívají různé strategie k mapování mezi aplikačními a databázovými strukturami. Dvě hlavní kategorie jsou vzor aktivního záznamu a vzor mapovače dat .

Vzor aktivního záznamu se pokouší zapouzdřit data databáze do struktury objektů ve vašem kódu. Objekty obsahují metody pro uložení, aktualizaci nebo odstranění z databáze a změny vašich objektů se mají v databázi snadno projevit. Obecně platí, že aktivní objekt záznamu ve vaší aplikaci představuje záznam v databázi.

Implementace aktivních záznamů vám umožňují spravovat databázi vytvářením a propojováním tříd a instancí v rámci vašeho kódu. Protože tyto obecně mapují instance tříd přímo na databázové záznamy, je snadné si představit, co je ve vaší databázi, pokud rozumíte tomu, jaké objekty se ve vašem kódu používají.

Bohužel to může mít i několik zásadních nevýhod. Aplikace bývají velmi těsně propojeny s databází, což může způsobit problémy při pokusu o migraci do nové databáze nebo dokonce při testování kódu. Váš kód má tendenci spoléhat se na databázi, aby zaplnila mezery, které byly odstraněny z vašich objektů. "Magický" překlad mezi těmito dvěma doménami může také vést k problémům s výkonem, protože se systém snaží bezproblémově mapovat složité objekty na podkladovou datovou strukturu.

Vzor mapovače dat je dalším běžným vzorem ORM. Stejně jako vzor aktivních záznamů se mapovač dat pokouší fungovat jako nezávislá vrstva mezi vaším kódem a vaší databází, která mezi nimi zprostředkovává. Namísto snahy o bezproblémovou integraci objektů a databázových záznamů se však zaměřuje na pokusy o oddělení a překlad mezi nimi, přičemž každý z nich může existovat nezávisle. To může pomoci oddělit vaši obchodní logiku od podrobností souvisejících s databází, které se zabývají mapováním, reprezentací, serializací atd.

Takže spíše než nechat systém ORM zjistit, jak mapovat mezi objekty a databázovými tabulkami, je vývojář odpovědný za explicitní mapování mezi těmito dvěma. To může pomoci vyhnout se těsnému propojení a zákulisním operacím za cenu výrazně více práce při hledání vhodných mapování.

Výhody ORM

ORM jsou oblíbené z mnoha důvodů.

Pomáhají abstrahovat základní datovou doménu na něco, o čem lze snadno uvažovat v kontextu vaší aplikace. Spíše než uvažování o ukládání dat jako o nezávislém systému vám ORM pomáhají přistupovat k datovým systémům a spravovat je jako rozšíření vaší současné práce. To může vývojářům pomoci rychleji pracovat na základní obchodní logice, místo aby se zabředli do nuancí jejich backendů úložiště.

Dalším vedlejším efektem toho je, že ORM odstraňují mnoho standardních prvků nezbytných pro rozhraní s databázemi. ORM se často dodávají s nástroji pro migraci, které vám pomohou spravovat změny schématu databáze na základě změn provedených ve vašem kódu. Pokud váš ORM může pomoci se správou změn ve struktuře databáze, nemusíte nutně předem vymýšlet dokonalé schéma databáze. Změny vaší aplikace a databáze jsou často stejné nebo úzce související, což pomáhá sledovat změny v databázi při provádění změn v kódu.

Nevýhody ORM

ORM nejsou bez chyb. V mnoha případech vycházejí ze stejných rozhodnutí, kvůli kterým jsou ORM užitečné.

Jedním ze základních problémů s ORM je pokus o skrytí detailů databázového backendu. Toto zmatení usnadňuje práci s ORM v jednoduchých případech nebo v malých časových měřítcích, ale často vede k problémům, protože složitost roste.

Abstrakce není nikdy 100% úplná a pokus o použití ORM bez pochopení základního dotazovacího jazyka nebo struktury databáze často vede k problematickým předpokladům. To může ztížit nebo znemožnit ladění a ladění výkonu.

Snad nejznámějším problémem práce s ORM je nesoulad objektově-relační impedance, termín používaný k popisu obtížnosti překladu mezi objektově orientovaným programováním a relačním paradigmatem používaným relačními databázemi. Nekompatibilita mezi datovými modely používanými těmito dvěma kategoriemi technologií znamená, že s každým nárůstem složitosti je nezbytná další, nedokonalá abstrakce. Nesoulad mezi objektově-relační impedancí byl nazýván Vietnamem počítačové vědy (v odkazu na vietnamskou válku) kvůli jeho tendenci časem zvyšovat složitost a vést k situacím, kdy jsou cesty k úspěchu nebo změně kurzu obtížné nebo nemožné.

Obecně platí, že ORM bývají pomalejší než alternativy, zejména u složitých dotazů. ORM často generují komplikované dotazy pro relativně jednoduché databázové operace, protože používají obecné vzory, které musí být dostatečně flexibilní, aby zvládly jiné případy. Spoléhání se na to, že ORM udělá za všech okolností správnou věc, může vést k nákladným chybám, které může být těžké dohnat.

Přehled ORM

ORM mohou být užitečné abstrakce, které práci s databázemi značně usnadní. Mohou vám pomoci rychle navrhnout a iterovat a překlenout koncepční rozdíly mezi aplikační logikou a strukturami databáze. Mnohé z těchto výhod však působí jako dvousečná zbraň. Mohou vám bránit v pochopení vašich databází a mohou ztížit ladění, změnu paradigmat nebo zvýšení výkonu.

Glosář

Při práci s technologiemi, které tvoří rozhraní mezi databázemi a aplikacemi, se můžete setkat s terminologií, kterou neznáte. V této části stručně projdeme některé z nejběžnějších termínů, se kterými se můžete setkat, z nichž některé byly popsány dříve v tomto článku a některé nikoli.

• Mapovač dat: Mapovač dat je návrhový vzor nebo část softwaru, která mapuje programové datové struktury na struktury uložené v databázi. Datové mapovače se pokoušejí synchronizovat změny mezi těmito dvěma zdroji a zároveň je udržovat na sobě nezávislé. Samotný mapper je odpovědný za udržování funkčního překladu a umožňuje vývojářům opakovat datové struktury aplikace bez starostí o reprezentaci databáze.
• Ovladač databáze: Ovladač databáze je část softwaru navržená k zapouzdření a umožnění připojení mezi aplikací a databází. Databázové ovladače abstrahují nízkoúrovňové podrobnosti o vytváření a správě připojení a poskytují jednotné programové rozhraní databázovému systému. Ovladače databází jsou obvykle nejnižší úrovní abstrakce, kterou vývojáři používají k interakci s databázemi, přičemž nástroje vyšší úrovně staví na možnostech, které poskytuje ovladač.
• Útok injekcí: Injekční útok je útok, při kterém se uživatel se zlými úmysly pokouší provést nechtěné databázové operace pomocí speciálně vytvořeného vstupu v polích aplikace pro uživatele. Často se to používá k načtení dat, která by neměla být přístupná, nebo k vymazání či pozměnění informací v databázi.
• ORM: ORM, neboli objektově-relační mapovače, jsou abstraktní vrstvy, které překládají mezi reprezentacemi dat používanými v relačních databázích a reprezentací v paměti používanou u objektově orientovaného programování. ORM poskytuje objektově orientované rozhraní pro data v databázi, snaží se snížit množství kódu a používat známé archetypy k urychlení vývoje.
• Nesoulad objekt-relační impedance: Objektově-relační nesoulad impedance se týká obtížnosti překladu mezi objektově orientovanou aplikací a relační databází. Protože se datové struktury výrazně liší, může být obtížné věrně a výkonně mutovat a přepisovat programové datové struktury do formátu používaného backendem úložiště.
• Rámec persistence: Rámec persistence je vrstva abstrakce middlewaru vyvinutá k překlenutí mezery mezi daty programu a databázemi. Trvalé rámce mohou být také ORM, pokud abstrakce, kterou používají, mapuje objekty na relační entity.
• Nástroj pro tvorbu dotazů: Tvůrce dotazů je abstraktní vrstva, která pomáhá vývojářům přistupovat k databázím a řídit je tím, že poskytuje řízené rozhraní, které přidává funkce použitelnosti, bezpečnosti nebo flexibility. Tvůrci dotazů jsou obvykle relativně nenároční, zaměřují se na usnadnění přístupu k datům a jejich reprezentaci a nepokoušejí se převést data do konkrétního programovacího paradigmatu.
• SQL: SQL, neboli strukturovaný dotazovací jazyk, je doménově specifický jazyk vyvinutý pro správu systémů správy relačních databází. Lze jej použít k dotazování, definování a manipulaci s daty v rámci databáze i jejich organizačních struktur. SQL je mezi relačními databázemi všudypřítomné.

Závěr

V tomto článku jsme se podívali na několik různých možností pro propojení s vaší databází z vaší aplikace. Zkoumali jsme různé úrovně abstrakce a flexibilitu, kterou nabízí použití databázových nativních dotazovacích jazyků, jako je SQL, pomocí nástroje pro tvorbu dotazů, který pomáhá bezpečně vytvářet dotazy, a ORM, které poskytují úplnější úroveň abstrakce.

Každý z těchto přístupů má své využití a některé mohou být pro určité typy aplikací vhodné než jiné. Je důležité porozumět požadavkům vaší aplikace, znalostem databáze vaší organizace a nákladům na abstrakce (nebo jejich nedostatek), které se rozhodnete implementovat. Celkově vzato, pochopení každého přístupu vám dá nejlepší šanci vybrat si možnost, která bude pro vaše projekty vhodná.