{{predmet|Databáze typu klient-server|Tomáš Rubač|DBI004}}
= Info =
Celkem poutavá přednáška o SQL z praktického hlediska.
== Zápočet ==
* triviální SQL program na dvou tabulkách (nemusí být velký, stačí kousek kódu).
* vše ošetřené v databázi: integrita, triggery, procedury k sahání (i s ošetřením výjimek).
* 50-60 řádek.
== Zkouška ==
* jednoduchá písemka (zadání podobné zápočťáku).
* přepsat datový model do SQL i s nějakými triggery/procedurami.
* nějaké ústní otázky.
* není potřeba zápočet.
=== Termíny v LS 2004/2005 ===
* 25.05.2005 S3 17:30
* 09.06.2005 S3 17:30
* 23.06.2005 S3 17:30
= Poznámky =
== DDL - Date definition language ==
== DML - Data manipulating language ==
== Zámky ==
== Kurzory ==
== Procedury/funkce ==
== Triggery ==
Procedura automaticky spuštěná na základě nějaké události (login a logout uživatele, insert, update a delete nad tabulkou, při systémové chybě).
'''create [or replace] trigger [někdy_jde_pojmenovat] on <jméno_tabulky> [before/after/instead of] [insert/update/delete]'''
* jeden trigger na tabulku teoreticky stačí, ale když se k tomu dostane víc lidí, tak se mezi sebou pobijí. Když je triggerů na jednu věc víc, jejich pořadí je nedefinované.
* užitečné k ošetřování stavových sloupců a podobných záležitostí (pak je špatné, když trigger nedopatřením odpadne).
* triggery výrazně zpomalují výpočty, dají se dočasně sundat pomocí disable trigger (když má uživatel právo alter trigger).
* dají se spouštět buď po každém řádku (FOR EACH ROW) nebo jednou za všechny řádky (FOR EACH STATEMENT).
* v insert triggeru vidím nové hodnoty, v delete staré, v update nové i staré. Speciální tabulky new a old (chovají se jako normální tabulky, new se dá upravovat před vložením) (v Oraclu je místo virtuální tabulky defaultně jakýsi record :new, dá se to definovat pomocí klauzule referencing).
* instead of triggery dobré k simulaci vkládání do pohledů, do kterých to normálně nemusí jít.
* update triggery se spouští řádek po řádku.
* v triggeru se nesmí sahat na tabulky, které už triggery ošetřují (takže se nedá udělat cyklické věčné zaplnění).
* v update triggerech se dá používat příkaz if updated (...), který ověřuje, jestli dané sloupce byly změněny.
* triggery mohou pomocí raise error (sp?) házet tajemné a těžko dohledatelné chyby.
* trigger může na některých serverech pomocí příkazu rollback transaction sundat celou operaci, která trigger vyvolala (ne celou transakci jako normální rollback).
* Dají se použít pro udržení konzistence databáze (kromě věcí, na které jsou constrainty). Když vím, že data jsou konzistentní, nemusím se pak zdržovat dodatečnými testy integrity.
* nedají se linkovat z jiných balíků, ale mohou je volat (dobré pro verzování, které s triggery moc nejde) až na příkazy jako rollback transaction výše, které mohou být pouze v triggerech.
== Paralelní/distribuované zpracování ==
* Dva uživatelské profily na jedné databází.
** Jednoduché, vždy běží obě zároveň, mohou na sebe snadno koukat. Replikuji pomocí triggerů.
** Při upgradu (i bez změny) se ale triggery zneplatní a musí se ručně opravit. Dá se filtrovat přes pohledy. Při změně se musí zastavit obě části.
* Dvě databáze blízko sebe (na lokální síti).
** Triggery selžou při výpadku jednoho stroje. Databáze nebudou konzistentní.
** Řešení: procedury, které budou jednosměrně aktulizovat data.
*** Sypač: Dávám si data do fronty, pak ji procedura jednou za čas přesype na druhou stranu. Fronta je ale citlivá, protože si při updatu můžu pokazit její triggery.
*** Olizovač: Periodicky očumuji druhou databázi, a sosám si nové věci.
*** Olizovač fronty: Jedna strana připravuje frontu, druhá ji nasává.
** Synchronizační proces by měl běžet nezávisle na aplikaci. Změny by se měly v obou aplikacích promítat současně – dvoufázový commit (viz [[Transakce]]).
* Vzdálené databáze.
** Data se musí opravdu posílat sem a tam.
** Typický problém: Pobočka v Praze i v Brně zároveň přidají do číselníku nový výrobek. Po synchronizaci je výrobek v databázi dvakrát (kvůli závislým položkám už nemusí jít ani jeden smazat). Řešení:
*** Administrativní opatření - vkládat do číselníku zboží lze jen v praze.
*** Předávaní peška - pešek před sebou tlačí všechny updaty a jen ten kdo má peška může vkládat do číselníku.
* Spojení ven z databáze a další featury
** Posílací fronty přímo v systému – Oracle Advanced Queing (moc drahé).
** Pipe – nadefinuji trubku, pak do ní posílám data. Na druhé straně z musí data z trubky něco požírat (<pipe> load). Trubka je asynchronní a neřídí se pravidly pro transakce – dobré pro ladící výpisy, ale pro nic jiného.
** Alerter – vystaví majáček, a když se něco stane, tak na něj vypustí alert, který se chová podle transakcí. Procesy koukající na alerty se musí zaregistrovat, a server je pak obešle zprávou. Tím se dá řešit upozornění na stažení updatu při blízkých databázích.
** Job – vlastnost databáze, která plánuje úlohu ke spuštění (jako at/cron).
== Provázaní s aplikací ==
= Odkazy =
* [http://urtax.ms.mff.cuni.cz/~novap2am/poznamky/databaze2.sxw Poznámky z přednášky]
