Saglabātās procedūras

SQLs, protams, ir laba, spēcīga un spējīga datu apstrādes valoda, tomēr reižu reizēm ar to nepietiek. Tiesa gan pirms ķerties pie kaut kā vairāk noteikti ir jāpārliecinās, ka ar SQL vien nepietiek, atceroties, piemēram, tādas lietas kā grupēšanas, apakšvaicājumus, savienojumus, analītiskās funkcijas, model klauzas u.c. iespējas. Sīkāk par to, kādā kārtībā vajadzētu mēģināt risināt problēmas, rakstīju pagājušoreiz.

Tomēr, ja biznesa loģika un realizējamie algoritmi ir pārāk sarežģīti, tad nākas ķerties pie kaut kā sarežģītāka un ar lielākām iespējām un tās ir iebūvētās (reizēm laikam saka arī iegultās vai barbarisms storētās, no angļu stored) procedūras un funkcijas. Lielāka daļa DBVS (tālāk būs viens un tas pats piemērs Oracle, SQL Server un MySQL), kas cenšas attīstīt un piedāvāt lielāku funkcionalitāti, ir izveidojušas vai paņēmušas jau esošu programmēšanas valodu, kurā tad šīs procedūras un funkcijas var veidot. Būtiski ir tas, ka šīs procedurālās vienības tiek glabātas datubāzē. Tā ir pirmā un pati būtiskākā atšķirība, kas tās atšķir no jebkuras citas procedūras vai funkcijas, kas izveidotas un parasti atrodas uz klienta (klienta-servera sistēmā) vai lietojumprogrammu servera (application server) trīs līmeņu sistēmā. Tas faktiski arī nosaka šo procedurālo vienību labās un sliktās īpašības salīdzinājumā ar parastām procedūrām un funkcijām.

Procedūru un funkciju lietošanas mehānisms ir šāds:

1. Vispirms procedūra vai funkcija tiek izveidota, saglabāta un nokompilēta datubāzē. To dara līdzīgi kā ar jebkuru citu datubāzes objektu, izmantojot CREATE PROCEDURE vai CREATE FUNCTION SQL DDL teikumu. Šai brīdī procedūra vai funkcija tiek tikai izveidota, tā vēl netiek pildīta. Šai brīdī parasti DBVS veic arī zināmas pārbaudes, vai procedūra/funkcija ir korekta sintaktiski, vai ir pieejami tajā minētie objekti u.c.
2. Pēc tam, kad procedūra vai funkcija ir veiksmīgi izveidota un bez kļūdām nokompilēta, to var izpildīt (execute). Katrā DBVS to dara mazliet atsķirīgi, bet šis ir tas brīdis, kad visa procedūrā vai funkcijā iekodētā loģika tiešām tiek izpildīta un iegūts (cerams vēlamais 😉 ) rezultāts.

Tālāk neliels iebūvētās procedūras piemērs visās trīs tradicionāli manis aprunātajās DBVS.

MySQL Workbench – datu modelēšanas rīks

Iepriekšējo reizi rakstīju par savu pieredzi darbā ar Oracle Designer, Grade modeler un Visio. Tā kā pārāk daudz apskatīt reizē nesanāks, šoreiz būs tikai par vienu MySQL Workbench. Bet vispirms par aptauju, kurai jau pieaugusi neliela bārda. Tātad iepriekšējā reizē jautāju lasītājiem, kādus datu modelēšanas rīkus nācies izmantot. Rezultāti ir šādi:

Datu modelēšanas rīku popularitāte

Kopā bija 77 balsis, no kurām gandrīz trešdaļa (30%) izvēlējās Visio, otrajā vietā ar 19% bija MySQL Workbench, bet trešajā Grade Modeler ar 12%, ceturtajā Designer ar 11%. Pārējiem visiem piekritēju bija mazāk nekā 10%.

Nu tad ķeramies pie godājamā otrās vietas ieguvēja MySQL Workbench. Instalāciju tam var atrast šeit. Rīks ir bezmaksas jeb precīzāk tā Community redakcija ir pieejama ar GPL licenci.

Sākumā dažas svarīgākās lietas:

• Rīks ir domāts tikai un vienīgi MySQL datubāzei.
• Rīkam ir divas redakcijas (editions). Community ir pieejama bezmaksas, bet Standarta ir par maksu ar papildus iespējām, piemēram, datubāzes dokumentācijas ģenerēšanu.
• Vismaz jaunākajā 5.2 versijā ar to var darīt jau trīs lietas:
  • veidot datubāzes modeļus;
  • izpildīt SQL pieprasījumus;
  • veikt MySQL datubāzes administrēšanu.

Izvērstu tā iespēju uzskaitījumu un salīdzinājumu pa redakcijām var redzēt šeit.

Tālāk pievērsīsimies šī rīka datu modelēšanas iespējām. Nākošajā attēlā var uzskatāmi redzēt šī rīka maza datu modelīša piemēru.

MySQL workbench datu modeļa piemērs

Uzskatāmi ir iezīmētas primārās atslēgas (dzeltena atslēdziņa), obligātie lauki (aizpildīts rombiņš), ārējās atslēgas (rozā rombiņš), datu tipi un indeksi, protams arī redzami, bet tos var arī aizvākt. Kopējais rīka izskats ir šāds:

MySQL Workbench Ekrānforma

Rīku iepētīju diezgan minimāli, bet daži iespaidi radās:

• Tam ir tikai datu modelis, nav entītiju modelis. Tiesa gan, tas rīka izstrādātājiem veidojamos modeļus nav liedzis nosaukt par EER modeļiem, tā kā es šādu saīsinājumu redzēju pirmo reizi, tad pajautāju Googlei, kas tā tāda EER diagramma. Atradu ka tā saucās uzlabotā ER diagramma (enhanced ER-diagram) un šeit arī kāda Sanhosē universitātes ķīniešu profesora prezentāciju par šo. Nu ja pieņem, ka šī profesora viedoklis ir pareizs, tad gan šim rīkam ar viņa iespējām līdz ENHANCED ER diagrammai, piedodiet par izteicienu, kā cūkai līdz mēnesim 🙂
• Saitēm nav iespējams mainīt gala punktus pie kastītēm, tie tiek noteikti automātiski. Man ir aizdomas, ka sarežģītāku diagrammu gadījumā tas būtu diezgan nepatīkami.
• Tabulām ir iespējams mainīt izmērus (tās staipīt), tas neapšaubāmi ir pozitīvi, jo lai izveidotu pārskatāmu diagrammu šī lieta ir ļoti nepieciešama.
• Rīks ļauj datu modelī attēlot un uzturēt arī skatījumus un saglabātās koda vienības.
• Rīks ļauj ģenerēt kodu no modeļa (forward engineer), kā arī ievilkt jau esošas datubāzes tabulas modelī (reverse engineer). Kas vēl trakāk, tas ļauj arī salīdzināt izmaiņas un tās ievilkt vai nu modelī vai izveidot datubāzē. Tiesa gan izmaiņas tiek parādītas tikai objektu līmenī, piemēram, kaut kas tabulas definīcijā ir mainījies, bet nu jebkurā gadījumā tas ir ļoti labi. Salīdzināšanas ekrāns ar jau izvēlētām mērķa iespējām (ignorēt, DB->modelis, modelis->DB) izskatās šādi:

Datubāzes un modeļa sinhronizācija

Nobeigumā varu izteikt tikai vienu secinājumu – katrā ziņā rīks izskatās simpātisks, tam ir diezgan daudz visādu iespēju un tas noteikti ir gana noderīgs, ja nepieciešams izmantot MySQL DBVS.

MySQL lietotāja definētie mainīgie un paplašinātais izpildes plāns

Raksts būs par divām lietām, kuras vieno faktiski tikai tas, ka tās ir saistītas ar MySQL. Uzdūros tām atbildot uz jautājumiem Latvijas programmētāju forumos, cik nu mums vispār te tādu ir.

Un tātad pirmais stāsts ir par MySQL lietotāja definētajiem mainīgajiem SQLā. Daudzām DBVS ir savi procedurālie paplašinājumi SQL, piemēram, Oracle tas ir PL/SQL, Microsoft SQL Server tas ir Transact-SQL jeb saīsinot T-SQL, MySQL arī 5.0 versijā pirmo reizi parādījās saglabātās procedūras un funkcijas. Tomēr jau no 3.23.6 versijas ir kaut kādi iedīgļi – lietotāja definētie mainīgie. Viens no populāriem to pielietojumiem, piemēram, ir ģenerēt numurus pēc kārtas, kas itin bieži ir nepieciešams, bet citā veidā MySQL nav iespējams. Piemērs, kurā ir tabula ar primārās atslēgas lauku, kurš ir unikāls, bet nenodrošina numurus pēc kārtas (kas tam, protams, NAV ARĪ JĀDARA!):

MySQL un Oracle sāga turpinās

Kā zināms nu jau labu laiciņu Oracle precību rezultātā ar Sun ieguva arī MySQL DBVS. Tiesa gan kā jau nopietnas precības arī šīs ir jāapstiprina oficiāli visādām tur konkurences padomēm un tamlīdzīgām organizācijām. Eiropas Savienība, kā jau pamatīgi birokrāti, šo procesu vilka vairāk nekā pusgadu, pa ceļam sākot padziļinātu izpēti tieši darījuma daļā, kas saistās ar Oracle un MySQL DBVS. Tomēr nupat pirms dažām dienām paziņoja, ka apstiprina darījumu, pamatojot to ar faktu, ka Oracle un MySQL nav konkurenti “smagā gala” (high-end) tirgū, kam pat varētu vismaz daļēji piekrist. Tāpat komisija atzīmē, ka daudzi DBVS lietotāji uzskatot, ka PostgreSQL esot gana laba alternatīva MySQL, kuru var izmantot nepieciešamības gadījumā.

Sāga vēl arī pilnībā nav beigusies, jo darījums jāapstiprina vēl Ķīnā un Krievijā, taču vismaz Oracle pati saka, ka šie apstiprinājumi drīz sekošot, kad beidzot vismaz juridiski pasākums būs noslēdzies.

Pa vidu vēl bija visai interesanti notikumi, piemēram, MySQL dibinātājs Michael Widenius aka Monty, pat sauca visiem glābt MySQL un kura rezultātā (iespējams arī, lai iespaidotu Eiropas Savienības lēmumu labvēlīgā virzienā) radās  Oracle’s 14. decembra paziņojums, kas varētu kaut nedaudz mierināt MySQL zvērīgos zēlotus un kurā Oracle sola daudzas labas lietas, tai skaitā:

• Turpināt atbalstīt un uzlabot esošo dažādu glabāšanas dziņu lietojumprogrammas saskarni (Storage engine API).
• Arī nākotnē turpināt uzlabot MySQLu un izplatīt to atbilstoši GPL licencei.
• Pēc komerciālas licences nopirkšanas neprasīt obligātu uzturēšanas līguma noslēgšanu. Šis ir ļoti interesants punkts, jo saskaņā ar Oracles datiem tās ienākumi no uzturēšanas ir vienkārši zvērīgi (3,24 miljardi $) un uzturēšana ir nenormāli ienesīga daļa visa uzņēmuma biznesā (attiecīgi izdevumi šai sadaļā tikai 0.26 miljardi). Abas pārējās nozares – jaunu licenču pārdošana un pakalpojumi kopā ir ieņēmušas krietni mazāk un izdevušas krietni vairāk, galu galā strādājot ar zaudējumiem. Protams, jautājums paliek, kā tiek skaitīti ieņēmumi un izdevumi 🙂
• Palielināt finansējumu MySQL izstrādei salīdzinot ar to, ko izdeva SUN.

Tai pašā laikā Monty turpināja stāstīt, ka tas viss ir tikai tukši solījumi un aicināja saglābt interneta brīvestību, kurā faktiski atbildēja uz biežāk uzdotajiem jautājumiem, kāpēc viņam tik ļoti šis pasākums nepatīk un, piemēram, kāpēc tad pats MySQLam ļāva nokļūt SUN rokās. Kā jau tas gaidāms radās arī atbildes uz Monty paziņojumiem, kaut vai šī, kas maigi izsakoties visai skeptiski vērtē viņa soļus.

Raksts sanāca tāds baisais saišu apkopojums, bet tas viss šķita gana interesanta info, ar kuru nevarēju nepadalīties 😉

Pirmo N ierakstu atlase

Atlasīt pirmos N (2, 3, 5, 10, 20, 100 utt.) ierakstus ir diezgan izplatīta prasība. Atlasīt N lielākos, N mazākos, N jaunākos utt. Angliski to parasti sauc kā Top N analysis vai Top N Query. Savukārt (parasti webiskās aplikācijās) mēdz būt vēl viena diezgan tipiska prasība – lapošana (pagination) – ierakstu atlase pa porcijām. Šīs ir tās lietas, kur datu bāzu vadības sistēmu atšķirības spīd visā savā spožumā. Tikai relatīvi pēdējā laikā izmantojot analītiskās funkcijas vismaz dažās DBVS var mēģināt izlīdzēties ar vienu un to pašu SQL teikumu pirmo N ierakstu atlasē un lapošanā. Kā jau vienmēr esmu mēģinājis uzsvērt, tas gan nebūtu jāuzskata par milzīgu trūkumu, jo arī, iekāpjot cita ražotāja automašīnā, Jūs negaidat, ka ātruma pārslēgs slēgsies precīzi tāpat ka iepriekšējā. Truli laužot to pierastajā pozīcijā, Jūs varat iegūt tikai salauztu mašīnu un ar datubāzēm, protams, ir līdzīgi. Tiktāl ievads, bet tagad pēc kārtas par Oracle, MySQL, SQL Server un analītisko funkciju universālo risinājumu.