Výhody databázových procedur
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Reklama

Výhody databázových procedurVýhody databázových procedur

 
Hledat
Moderní platforma pro vytvoření vašeho nového webu – Wix.com.
Nyní už můžete mít web zdarma.
Vybavení pro Laser Game
Spuštěn Filmový magazín
Laser Game Brno

Výhody databázových procedur

Google       Google       25. 3. 2008       19 872×

Databázové procedury jsou jednou z vývojářských praktik, na kterou většina aplikačních vývojářů, podle mého názoru, hledí se značným despektem. Jsou využívány u velkých aplikací v bankovnictví nebo telekomunikacích, ale u menších a středně velkých aplikací současné trendy spíše směřují k objektově-relačnímu přístupu (ORM). Kde to jen jde, je snaha „zadrátovat“ práci s daty do aplikační vrstvy. Kámen úrazu ale většinou nastane, pokud se nároky na zátěž aplikace zvýší nebo je včleněna do podnikové infrastruktury.

Reklama
Reklama

Výkon, bezpečnost a závislost

Díky separování práce s daty a vlastních dat mezi různé vrstvy (aplikační/prezentační a datová) jsou přenášeny zbytečné objemy dat, které přitom mohly zůstat v databázi. Slabou stránkou v tuto chvíli je nejen vysoká zátěž způsobená přenosem po síti, ale také bezpečnost, protože databáze nechává napospas klientské aplikaci celou svoji strukturu (aniž by to bylo vůbec potřeba). Jakmile začne aplikace růst, obvykle se ozývají hlasy, že databáze je pomalá a nestíhá s výkonem. Opak je pravdou – databáze je rychlá, pouze díky velmi špatnému návrhu aplikace musí pracovat s větším objemem dat, než je nutné. Po stránce bezpečnosti mají databázové procedury ještě další výhodu. Obsahují typovou kontrolu a díky tomu jsou odolné vůči útoku script-injection, o kterém je v poslední době slyšet poměrně často.

U rozsáhlejšího systému je velkou výhodou centralizovaná logika. Změny výpočetních algoritmů můžete provádět na jednom místě (v databázi), aniž musíte zjišťovat, kde všude je logika „zadrátovaná“. Také je asi zřejmé, že pokud je pomalá práce s daty, bude pomalý i celý zbytek systému. Jistě lze namítnout, že logiku můžeme centralizovat přímo v aplikaci a v rámci firemní struktury ji poskytovat jako webovou službu. To je sice možné, ale stále se nezbavíme velkého objemu zpracovaných a přenášených dat (úzké hrdlo architektury je zobrazeno na obrázku).

Výhody databázových procedur

Smyslem databázových procedur je přenesení logiky, která pracuje s daty, na stranu databáze. V rámci jednoho volání z aplikační vrstvy tak máme možnost s daty provést všechny potřebné operace a předat pouze výsledek, který je okamžitě použitelný. Zároveň se nám nabízí velmi široký arzenál funkcí, který můžeme v databázi aplikovat – počínaje analytickými funkcemi pro statistické výpočty, logování, auditování a konče nepřebernými technikami ladění. Aplikační vrstvě zůstává tato logika zcela skryta a je jí poskytnuta pouze služba ve formě rozhraní (API), přes které databázi volá.

Pro názornost uvažujme aplikaci mobilního operátora, která plní funkci účetního systému evidujícího zaúčtované operace (volání, SMS, MMS atd.). Periodicky je generován report složený z více dotazů, který je formou faktury zaslán zákazníkovi nebo je zpřístupněn na webu. To vše samozřejmě v hromadném zpracování (dávce), vždy pro část zákazníků se stejným zúčtovacím obdobím. Je rozumné všechna data zpracovávat na aplikační vrstvě nebo dávku zpracovat v databázi a aplikační vrstvu nechat výsledek pouze využít? Odpověď je asi zřejmá. U velkých objemů dat může takováto operace trvat i několik hodin a osobně se domnívám, že čím méně vrstev do tohoto zpracování zasahuje, tím lépe. S tím souvisí i stabilita databázového spojení, kterou je potřeba udržet, protože při jeho „vytuhnutí“ provede databáze automaticky zrušení celé transakce.

Velkou výhodou je skutečnost, že jednotlivé vrstvy zajišťují pouze to, k čemu jsou určeny: aplikační vrstva aplikační logiku a datová vrstva práci s daty. Optimalizace tak může probíhat na jednotlivých vrstvách nezávisle a je jedno, jestli v databázi uplatníme refaktoring procedur, provedeme denormalizaci tabulek nebo zvolíme jiné techniky ladění (přístup optimalizátoru, materializované pohledy, partitioning atd.).

Druhá strana mince

Jednou z častých výtek bývá příliš velká závislost na databázi, protože každý databázový systém poskytuje jiný soubor funkcí a zároveň se liší i jednotlivé postupy při ladění. Je-li naším cílem vytvořit obecný přístup, který bude fungovat na více platformách, zpravidla se ochuzujeme (ať záměrně nebo ne) o výkonné funkce, které jsou závislé na konkrétní databázi. Ani základní vlastnost, jako je inkrementace primárního klíče, není implementována na všech platformách stejně (jedna využívá typ increment, další zase sekvence). U složitějších funkcí, které ovšem přinášejí největší výkonový rozdíl, je to podobné.

Pro zákazníka není důležité, jestli aplikaci může nasadit na více databázích. Zajímá ho, jestli dobře (a dostatečně rychle) funguje na té jeho.

Vývoj aplikace pro více databázových systémů není jednoduchý a vůbec ne levný, proto si položím filozofické otázky:

  1. Jaká je pravděpodobnost, že naše aplikace bude využita na jiných databázových platformách? (U velkých organizací téměř mizivá. I menší projekty fungují stabilně na jedné databázi, ať už se jedná o MySQL nebo PostgreSQL, a jejich portace na jinou platformu je spíš výjimkou.)
  2. Vyvíjíme krabicový produkt, který budeme nabízet zákazníkům využívající rozdílné databáze? (Skutečně si můžeme dovolit luxus, abychom aplikaci činili takto přenositelnou?)

Porovnání přístupů

Volání SQL dotazů

Výhody:

  • jednoduché na naučení (žádné znalosti kromě základních SQL příkazů),
  • nezávislost na databázi (relativní).

Nevýhody:

  • přenášení/zpracování velkého objemu dat,
  • nízká bezpečnost (script injection, přenášení nadbytečných dat pro mezivýsledky),
  • malé možnosti pro ladění a refaktoring,
  • nižší výkon v porovnání s databázovými procedurami.

Volání databázových procedur

Výhody:

  • přenášení pouze výsledku,
  • vysoká bezpečnost (typová kontrola, struktura databáze a dat skryta další vrstvě),
  • nástroje pro ladění často dostupné přímo od výrobce, zároveň ladíme odděleně podle vrstev,
  • provádění refaktoringu nezávisle na klientech a jiných částech systému,
  • vysoký výkon (možnost použití nativního zpracování),
  • možnost vyžití funkcí databázového serveru (analytické funkce, audit, práce s XML a další),
  • kontrola závislostí mezi objekty v době překladu (nikoliv runtime).

Nevýhody:

  • složitější na naučení (se znalostí základních SQL příkazů si nevystačíme),
  • závislost na databázi daného výrobce (Oracle PL/SQL, Microsoft T-SQL a další).

Závěr

Samozřejmě ani databázové procedury nejsou optimální za všech okolností. Třeba práce s objekty v postrelačních databázích není vůbec jednoduchá a celý proces ještě více znepříjemňuje mapování objektů mezi aplikační a datovou vrstvou. Například v databázi Oracle je nutné vytvořit pro objekty tzv. deskriptory, o kterých toho v české literatuře mnoho nenaleznete. Jestli jsou databázové procedury tou správnou volbou, závisí především na rozsahu a využití konkrétní aplikace. Příkladem, že databázové procedury nemusí být vhodné ani pro velké projekty, je třeba aukční portál eBay. (Nejedná se o výjimku potvrzující pravidlo?)

×Odeslání článku na tvůj Kindle

Zadej svůj Kindle e-mail a my ti pošleme článek na tvůj Kindle.
Musíš mít povolený příjem obsahu do svého Kindle z naší e-mailové adresy kindle@programujte.com.

E-mailová adresa (např. novak@kindle.com):

TIP: Pokud chceš dostávat naše články každé ráno do svého Kindle, koukni do sekce Články do Kindle.

Hlasování bylo ukončeno    
0 hlasů

Nové články

Obrázek ke článku SODAT vidí budoucnost datové bezpečnosti ve strojovém učení

SODAT vidí budoucnost datové bezpečnosti ve strojovém učení

Firmy chrání svá citlivá data často nedostatečně. Podle průzkumu společnosti SODAT se v minulém roce setkalo až 80 % z nich s bezpečnostním incidentem ztráty nebo úniku dat. Jedna z pilotních firem, která testovala novou verzi řešení SODAT Protection & Analytics 2.0pro bezpečností analýzu a monitoring dat díky novince zjistila, kdo z disku smazal důležité výkresy a mohla na incident včas reagovat.

Reklama
Reklama
Obrázek ke článku Kontrolujete pracovní emaily i na dovolené? 7 tipů odborníka, jak nepřijít o data

Kontrolujete pracovní emaily i na dovolené? 7 tipů odborníka, jak nepřijít o data

Letní měsíce jsou pro většinu zaměstnanců spojené s každoroční dovolenou. Z údajů Českého statistického úřadu vyplývá, že v roce 2017 podnikli Češi přes 13 milionů delších cest (tzn. s více než čtyřmi noclehy). Přitom právě na období července, srpna a září připadá více než 7,5 milionů z nich. Nicméně tradiční představu o dovolené jako o čase, kdy má práci na starost někdo jiný, Češi boří. 

Obrázek ke článku 10 SEO mýtů, které už nemusíte v roce 2018 řešit

10 SEO mýtů, které už nemusíte v roce 2018 řešit

„Kolik má být na stránce klíčových slov?“, „Nemáš vyplněný meta tag keywords, to nebude fungovat.“, „Katalogy jsou mrtvý“. Také jste už slyšeli některé z těchto otázek? Pojďme si na ně konečně jednou provždy odpovědět.

Obrázek ke článku Trend Micro pomohlo usvědčit viníky v mezinárodním případu Scan4You

Trend Micro pomohlo usvědčit viníky v mezinárodním případu Scan4You

Společnost Trend Micro Incorporated, globální lídr v oblasti kybernetické bezpečnosti, oznámila podrobnosti o své úzké spolupráci s FBI v případu Scan4You. Trend Micro se podílelo na identifikaci osob, které byly spojeny se službou Scan4You Counter Antivirus, což vedlo k jejich odsouzení.

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032018 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý