EXECUTES AS in MS SQL

EXECUTES AS – SQL Serveris gali apibrėžti vykdymo kontekstą funkcijoms, procedūroms, eilėms ir trigeriams. Taip galima valdyti, kas prieina prie informacijos.

EXECUTES AS:

CALLER – default nustatymas.

OWNER – jeigu modulis neturi specifinio savininko, tai bus naudojamas schemos savininkas.

SELF – vykdo tas, kas sukūrė ir atnaujino.

SCHEMABINDING in MS SQL

SCHEMABINDING pribindina view prie lentelės ar lentelių, iš kurių sudarytas view. Tada pagrindinės lentelės negali būti atnaujinamos, atnaujinant view.

Jeigu UDF (User Defined Function) sukurta su SCHEMABINDING, tai useris turi turėti REFRENCES savybes į visus objektus, kurie naudojami UDF. Visi UDF ir view, jei jie naudojami šioje funkcijoje, taip pat turi būti sukurti naudojant SCHEMABINDING.

Implementing functions

Funkcijos padeda paslėpti dažnai naudojamą logiką. Funkcija gali turėti arba neturėti parametrų, o gražina – skaliarinę reikšmę arba lentelę. Nepalaiko output parametrų.



Fukcijų tipai:

- scalar functions (su RETURN grąžina vieną reikšmę. Negali grąžinti text, ntext, image, cursor ir timestamps tipo duomenų.)

- inline table-valued functions (grąžina lentelę – tai vieno SELECT rezultatas)

- multi-statement table-valued functions(grąžina kelios užklausos, panašu į stored procedūrą)

- build-in functions (naudoja build-in fukcijas. Negali būti keičiama. Gali būti deterministic arba nondeterministic tipo – priklausomai, kaip naudojama)



Function:

- Deterministic (visada grąžina tą patį rezultatą pagal skirtingus input parametrus);

- Nondeterministic (pagal specifinius input parametrus grąžina skirtingus rezultatus).



Execution context valdymas



EXECUTE AS – t.y. tam tikras fukcijas gali vykdyti tik tam tikri naudotojai.

EXECUTE AS USER

EXECUTE AS LOGIN

Handling Exceptions

Struktūrinis klaidų gaudymas bendras daugelyje programavimo kalbų, tokių kaip Microsoft Visual Basic, Visual C#. Transact-SQL dažnai naudojamas klaidų gaudymas su TRY… CATCH.

Stored procedures in MS SQL

Stored procedūra –metodas, kuris inkapsuliuoja dažnai pasikartojančias užduotis. Jos palaiko apibrėžtus kintamuosius, sąlyginius vykdymus.
Stored procedūrų kūrimas panašus į view kūrimą – pirma sukuriam norimą užklausą, o po to – įdedame ją į procedūrą.
Jeigu procedūra sukurta naudojant WITH ENCRYPTION, tą pačią sintaksę naudoti reikia ir atnaujinat procedūrą.
Parameterized stored procedures
Gali turėti trijų rūšių komponentus:
Input parameters,

Output parameters,

Return values.

Execution plans


Execution planai parodo, kaip naudojamos lentelės, view’ai, indeksai vykdant užklausas.
Execution planai turi du pagrindinius komponentus:

- Query Plan

- Execution Context (specifiniai parametrai, pagal kuriuos vykdo užklausas. Šie parametrai skirtigi kiekvienam naudotojui – nes norima skirtingų duomenų)
Execution planai nėra parodomi encrypted stored procedures ir trigeriams.
Užklausos kompiliavimas, kai nėra kešuojami execution planai:

Parsing-> algebrized Tree -> Compilation -> Optimization


Stored procedūras galima rekompiliuoti:

- Sp_recompile

- WITH RECOMPILE on execution

- WITH RECOMPILE at creation

Views in MS SQL

Negali turėti daugiau kaip 1024 stulpelių

Negali naudoti COMPUTE, COMPUTE BY, INTO

Negali naudoti ORDER BY be TOP



Sys.views – sąrašas viewų duomenų bazėje

Sp_helptext – apibrėžia non-encrypted view

Sys.sql_dependencies – objektai (tame tarpe ir view), kurie priklauso kitiems objektams



Duomenų keitimas view’e

Atnaujinat view, duomenys pasikeičia ir pagrindinėje lentelėje
Negalima keisti stulpelių, kurie sudaryti naudojant GROUP BY, HAVING, DISTINCT

Indexed view

Indeksuotiems view’ams palaikyti reikia daugiau resursų, nei paprastiems indeksams.
Indeksuoti view’ai ir partitioned view gali pagerinti veikimą.
Norint indeksuoti view’ą, būtina naudoti SCHEMA_BINDING

Pirmasis indeksas view’w turi būti unikalus.

Indeksuoti viewai geriausiai veikia, kai būna retai atnaujinami duomenys lentelėse. Jei duomenys bus labai dažnai atnaujinami, indeksuotą view’ą palaikyti gali tapti per daug brangu.

Partitioned view


Į partitioned view galima sujungti horizontaliai padalintus duomenis iš vieno ar kelių serverių.
Partitioned view neturi būti maišomi su indeksuotais viewais, sukurtais partitioned schemoje.

OLTP vs. OLAP

IT sistemas galime suskirstyti į transactional (OLTP) ir analytical (OLAP).

OLTP - saugo duomenis, vykdo daug on-line transakcijų (INSERT, UPDATE, DELETE).
OLAP - analizuoja, duomenis vaizduoja įvairiais pjūviais.

paimta iš: http://datawarehouse4u.info/OLTP-vs-OLAP.html

Skirtumai tarp OLTP ir OLAP:

	OLTP System Online Transaction Processing (Operational System)	OLAP System Online Analytical Processing (Data Warehouse)
Source of data	Operational data; OLTPs are the original source of the data.	Consolidation data; OLAP data comes from the various OLTP Databases
Purpose of data	To control and run fundamental business tasks	To help with planning, problem solving, and decision support
What the data	Reveals a snapshot of ongoing business processes	Multi-dimensional views of various kinds of business activities
Inserts and Updates	Short and fast inserts and updates initiated by end users	Periodic long-running batch jobs refresh the data
Queries	Relatively standardized and simple queries Returning relatively few records	Often complex queries involving aggregations
Processing Speed	Typically very fast	Depends on the amount of data involved; batch data refreshes and complex queries may take many hours; query speed can be improved by creating indexes
Space Requirements	Can be relatively small if historical data is archived	Larger due to the existence of aggregation structures and history data; requires more indexes than OLTP
Database Design	Highly normalized with many tables	Typically de-normalized with fewer tables; use of star and/or snowflake schemas
Backup and Recovery	Backup religiously; operational data is critical to run the business, data loss is likely to entail significant monetary loss and legal liability	Instead of regular backups, some environments may consider simply reloading the OLTP data as a recovery method

source: www.rainmakerworks.com

OLAP systems really don’t like fragmentation, but OLTP systems do.