Saglabātās procedūras

februāris 15, 2011

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, savienojumusanalī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. Lasīt pārējo šī ieraksta daļu »


Brainbench testi

februāris 11, 2011

Nesen kārtējo reizi uzpeldēja saruna par testiem un sertifikātiem, konkrēti par Brainbench testiem. Visu testu skaits viņiem ir diezgan iespaidīgs, šobrīd ap 700. Tad nu lūk ieskatījos viņu mājaslapā un izrādās, ka bezmaksas testu sarakstā ir veseli divi, kas attiecas uz datubāzēm:

Tātad, ja kādam ir brīvs laiks un vēlme vai nu noskaidrot savu zināšanu līmeni, vai iepazīties, kas tad ar šo tēmu tiek saprasts un ko tur būtu vēlams zināt, ir visas iespējas pamēģināt testu. Jāatzīst, ka es neizturēju un arī mazliet paniekojos. Neiespringstot RDBMS testā (jo tur nav īsti kur iespringt, vai nu zinām jautājumu, vai nē) un krietni vairāk iespringstot SQL pamatlietu testā (jo tur jautājumi ir diezgan pretīgi un traki jārēķina where klauzas, piemēram) dabūju diezgan pieklājīgus rezultātus abos. Ja godīgi, nezinu vai jebkādam kādreiz šie testi ir palīdzējuši iegūt darbu vai lielāku algu, man personīgi nē, varbūt Jums ir cita pieredze? Vienīgo jēgu es tur varu saskatīt tādu, ka šādi testi pašam sev ļauj noskaidrot vājās vietas un dod priekšstatu par to, kas šai tēmā varētu tikt prasīts.

Tagad mazliet par vēsturi. Tais senajās dienās, kad Brainbench (sākumā vēl Tekmetrics) dzima, cik atceros, visi testi bija bezmaksas, acīmredzot, lai savāktu auditoriju un iebarotu potenciālos klientus. Kas vēl neticamāk, toreiz šie par velti arī sūtīja sertifikātus uz mājām, man vēl daži pat ir saglabājušies, viens piemēram izskatās šādi:

Tekmetrics (tagad Brainbench) sertifikāts

Tekmetrics (tagad Brainbench) sertifikāts

Tagad glabājas mājās kā vēstures liecība 🙂

Šodien gan diemžēl nekas tāds vairs par velti nenotiek, ja neskaita dažus testus, tad par visu pārējo ir jāmaksā, pat elektroniski atsūtītu sertifikātu. Vēl tomēr neticamā kārtā par velti var lejuplādēt logo, ko, piemēram, var lepni uzspraust savā weblapā 😀


Darbu secība

janvāris 19, 2011

Šis ir simtais ieraksts šai emuārā. Ievērojot šo apaļumu, gribējās rakstu mazliet īpašu un tad man ienāca prātā tradicionālā darbu secība, ko es itin bieži, piemēram, sevis lasītajos kursos mēdzu popularizēt. Atzīstos, ka neesmu šīs secības izgudrotājs, oriģināls ir pieejams šai grāmatā, es to tikai mazliet vispārināju un adaptēju 🙂 Tātad, izstrādājot programmatūru datubāzēm var izmantot šādu pieeju:

  • Labāk nedarīt neko;
  • Ja tomēr jādara, tad izmantojiet SQL;
  • Ja nav iespējams paveikt ar tīru SQL, tad izmantojiet iebūvēto programmēšanas valodu (PL/SQL –  Oraclē, Transact SQL – SQL Serverī utt.)
  • Ja to nav iespējams paveikt ar iebūvēto programmēšanas valodu, tad lietojiet kādu citu programmēšanas valodu – Java, C utt.
  • Ja to nav iespējams paveikt ar Java vai C (vai kādu citu izvēlētu programmēšanas valodu), tad stingri pārdomājiet, vai neķerties pie kāda cita darba.

Iespējams, ka daļai lasītāju šī pieeja šķiet mazliet provokatīva. Varbūt pat viņiem ir mazliet taisnība 😉 Tomēr tikai mazliet. Tagad daži komentāri par katru no punktiem. Lasīt pārējo šī ieraksta daļu »


Pirmo N ierakstu atlase

Oktobris 13, 2009

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.

Lasīt pārējo šī ieraksta daļu »


SQL teikuma izpildes plāna iegūšana – Oracle, MySQL, SQL Server

aprīlis 7, 2009

SQL teikumu izpildes plāns (query execution plan) – kurš gan nopietni interesējoties par datubāzu izstrādi tādu terminu nav dzirdējis? Vaicājums lēni strādā – paskaties izpildes plānu! Tiesa gan vairumā gadījumu tiek pašas par sevi pieņemtas divas (varbūt pat trīs) lietas:

  • persona zin, kā izpildes plānu dabūt;
  • persona zin, ko iegūtais izpildes plāns nozīmē;
  • persona zin, kā panākt, lai izpildes plāns būtu optimālāks nekā iegūtais vai arī saprot, ka nekas labāks nevar sanākt (neobligātais solis).

Šai rakstā apspriedīšu pirmo soli jau parasti izvēlētajām DBVS – Oracle, MySQL, SQL Server. Kā jau Jūs noteikti zinat visas DBVS ir atšķirīgas, attiecīgi atšķirīgas ir arī metodes, kā izpildes plānu iegūt. Tātad pēc kārtas.

Oracle

Oraclē ir vairākas metodes, kā iegūt SQL teikuma izpildes plānu, ar dažādu sarežģītību un ticamības pakāpi. Ja izmantojat rīku SQL*Plus, tad visvienkāršāk ir izmantot šī rīka komandu autotrace. Es šeit gari nekāvēšos pie šī rīka un komandas apraksta, jo tie abi ir augšminētajās saitēs, šeit tikai īss piemērs. Visiem turpmākajiem piemēriem tiks izmantotas tabulas no raksta par Dekarta reizinājumu. Lasīt pārējo šī ieraksta daļu »


Indeksu spožums un posts

marts 4, 2009

Kas ir indekss?

Indeksi popularitātes ziņā droši vien ir nākošie objekti datubāzēm pēc tabulām. Tos bieži izmanto vietā un iespējams gandrīz tikpat bieži patiesībā lieto nevajadzīgi. Bet tātad vispirms būtu jāsaprot, kas tad tie ir un kāda aptuveni ir to uzbūve.

Parasti runājot par indeksiem vispirms tos saprot kā kokveidīgu struktūru, kuras pirmais un galvenais uzdevums ir ātri atrast datus tabulā, kuras dati, ja vien tā nav ļoti speciāla veida tabula, ir nesakārtoti. Nākošajā attēlā ir parādīta konceptuāla indeksa struktūra. Protams, ka reālajās implementācijās katrā DBVS tas ir mazliet atšķirīgi, bet ideja paliek viena un tā pati – koks, pa kuru ātri nonāk līdz nepieciešamajai vērtībai un tad taisnā ceļā izmantojot norādes dodas uz tabulu, no kuras var nolasīt konkrēto ierakstu. Nevajadzētu, protams, arī uztvert datu bloku skaitīšanu kā precīzu algoritmu, kas pie šīm vērtībām tā arī notiek, bet drīzāk kā konceptuālu ideju.

Indekss un tabula

Indekss un tabula

Tātad, ja mēs meklējam vērtību “Kuldīga” (nosacījums WHERE pilsetas_nosaukums = ‘Kuldīga’) tabulā, tad mums ir divas iespējas: Lasīt pārējo šī ieraksta daļu »


7 lietas, ko nevajag darīt

janvāris 23, 2009

Arī mani ir sasniegusi sērga par 7 lietām, kas neesot par mani zināmas. Bet nu nekā nebija, es šeit netaisos pagaidām apspriest savas privātās lietas vai kaut ko tādu, kas pārāk tālu attālinās no datubāzēm un ar to saistīto. Ja vien mani nenovedīs līdz tam briestošo priekšvēlēšanu laikā 😉 Bet tagad nē. Tagad Jums būs 7 lietas saistītas ar datubāzes ātrdarbību (faktiski lēndarbību), ar kurām visām  es pašlaik cīnos vai man ir nācies cīnīties un par kurām varu izteikties tikai [cenzēts], [cenzēts], [cenzēts].

  1. Nelietojiet SQL vaicājumos lietotāja definētas (user-defined) funkcijas. Nelietojiet tās lieliem datu apjomiem. Vēl vairāk nelietojiet tās, ja tajās atkal kaut kas tiek lasīts no datubāzes. Un tas attiecas tikpat labi uz Oracle, kā uz SQL serveri. Izbaudu to uz savas ādas gandrīz katru reizi, kad nākas cīnīties ar bremzīgiem Select vaicājumiem. Kāpēc? Oracle tas ir tāpēc, ka vaicājums tiek nosacīti izpildīts zem SQL dziņa (SQL engine), savukārt jebkurš lietotāja definēts funkcijas izsaukums prasa PL/SQL dzini (PL/SQL engine) un mētāšanās no viena uz otru ir relatīvi dārgs process. To pašu esmu novērojis SQL Server, nezinu precīzu tehnisku skaidrojumu, bet tā vien izskatās, ka tur ir kaut kas ļoti līdzīgs.
  2. Nelasiet no datubāzes liekus datus. Nerakstiet SELECT * no 50 tabulām (jā 50!), rakstiet tikai tās kolonas no tām tabulām, ko Jums vajag. Tas ir pilnīgs ārprāts, ja Jūs atlasat 80 kolonas, jā 80! un pēc tam attēlojat 10. Un tas viss tikai tāpēc, ka šis vaicājums tagad derēs visās 17 vietās, kur Jums kaut ko no tā vajag attēlot. Autors par laimi (viņam) bija jau atlaists, citādi tas noteikti beigtos ar asinsizliešanu 😉
  3. Nekārtojiet liekus datus. Ja nu ir jākārto (ORDER BY) kādi dati, tad vienmēr raugieties, lai kārtojamo kolonu skaits nebūtu vairāk nekā nepieciešams. Nerakstiet SELECT * ORDER BY <1, 2, 3 kolonas>, ja izrādās, ka * nozīmē 20 kolonas no kurām tālāk Jūs lietojat tikai 10. Katra lieka kolona ir lieki dati, kas datubāzes serverim jātur atmiņā un jāvazā līdz kārtošanas laikā. Tā ir papildus atmiņa, papildus apstrādes laiks un bezjēdzīgi iztērēti resursi.
  4. Neatlasiet unikālās kolonas (DISTINCT jeb UNIQUE) tikai tāpat vien, drošības pēc. DBVS nezin, ka tas ir tikai tāpat, aiz nekā darīt. Ja tas patiesi ir pārāk bieži nepieciešams, tad diezgan droši tā ir kļūda datubāzes modelī. Kāpēc to nevajag? Tāpēc, ka katrs DISTINCT prasa unikālo ierakstu atlasi un jo vairāk kolonas tiks atlasītas, jo vairāk atmiņas un resursu tam būs nepieciešami. Ja tas ir izdarīts uz ierakstu kopu, kas jau tāpat ir ar unikāliem elementiem, tad tie ir burtiski zemē nomesti CPU cikli, atmiņas operācijas un iespējams pat diska apgriezieni.
  5. Nerakstiet dinamisko SQLu ar iešūtām mainīgo vērtībām. Datu bāzu vadības sistēmās (Oracle, MS SQL Server), kuru izstrādātāji ir ilgi pūlējušies, lai izveidotu kopīgu atmiņas apgabalu visiem SQL teikumiem (attiecīgi shared pool un procedure cache), maz kas var būt paradoksālāk kā nezinoši vai piedodiet par izteicienu stulbi izstrādātāji, kas katru savu SQL teikumu uzģenerē ar iešūtām mainīgo vērtībām, līdz ar to visus sākotnējos pūliņus izslaukot miskastē. Iešūtas mainīgo vērtības nozīmē praktiski nulles varbūtību, ka izveidotais SQL teikuma izpildes plāns būs lietojams arī nākošajam lietotājam, jo viņa SQL teikums būs gandrīz tāds pats, bet tikai gandrīz. Tajā atšķirsies iešūtie identifikatori vai arī kādi citi mainīgie un hopsā – tas vairs nav tas pats SQL teikums, kuram izpildes plāns jau bija zināms. Tā ir viena no tūkstoš hidras galvām, kam atkal jāpārbauda tiesības uz objektiem, jāģenerē savienojumu iespējamās kombinācijas un viss SQL teikuma izpildes plāns. Sīkums vienam lietotājam, kas reizi pusstundā palaiž SQL teikumu uz 15 minūtēm, bet nežēlīga sāpe kaut vai 10 lietotājiem, kuri katrs izpildītu desmitiem vai pat simtiem SQL teikumu sekundē, ja vien katram SQL teikumam nebūtu analīzes (parse) fāze, kas konstanti aizņem sekundi…
  6. Nelietojiet procedurālo valodu ciklus, lai apstrādātu ierakstus pa vienam, jo sevišķi, ja iterāciju skaits ir proporcionāls datu apjomam. Visizplatītākā lieta – kursori. Mans mazais skaistais kursoriņš, kurš izpildās zibenīgi uz dažiem ierakstiem, pārvēršas par milzīgu nekustīgu monstru, ja tas tikpat akli dodas caur reālajiem produkcijas miljons ierakstiem. Cikli, kuru iterāciju skaits ir tieši proporcionāls datu daudzumam nav savienojami ar vārdu ātrdarbība. Tie var būt tikai un vienīgi atbilstoši vārdam lēndarbība.
  7. Testējiet uz reālu datu apjomu, kādu Jūsu sistēma sasniegs pēc gada, diviem. Tas, ka Jūsu vaicājums izstrādes vidē uz 10 ierakstiem atgriež funkcionāli pareizu rezultātu zibenīgi ir nekas. Burtiski nekas. Sliktākajā gadījumā saģenerējiet datus pats, ja esošus reālus daudz nevar dabūt. Jo tad, kad Jūsu vaicājums sastapsies ar miljons ierakstiem, kam nāksies katram izsaukt lietotāja definētu funkciju, nolasīt visu ierakstu 50 kolonas, visu miljonu sakārtot dēļ liekā Distinct, un to darīs vismaz 10 lietotāji vienlaicīgi palaižot jūsu dinamiski ģenerēto SQL teikumu, lūk tad iestāsies brīdis, kad klients pacels cepuri un dosies pie Jūsu konkurentiem. Jo diemžēl lielāks dzelzis nederēs. Neviens dzelzis pie kaut cik ievērojama datu apjoma nespēj pārciest šeit uzskaitīto, tā lai lietotāji nesāktu dusmās vārīties un klusiņām lādēt izstrādātāju.

Man principā diez ko nepatīk visādas ķēdes un piramīdas, galu galā Medofs arī slikti beidza 🙂 , taču gribu pievērst lasītāju uzmanību vienam visnotaļ interesantam un (cerams, ka arī turpmāk) daudzsološam blogam, kurš raksta arī par lietām, kas saistās ar tīmekli un ātrdarbību.

Lasīt arī: