SQL ehk “Kuidas seda hääldada?”

Kordan igaks juhuks üle nende kõigi jaoks, kes tahavad maabuda

mõnele IT alasele tööpakkumisele, eriti Oracle andmebaasidega tegelevasse firmasse:
SQL hääldatakse kahte moodi:

“ess-kju-ell”.

(SQL -i peabki nii hääldama kõiki ANSI English keelereeglite kohaselt)

ja

“siii-kju-ell”. (SEQUEL tegelikult)

vt.

https://tuttman.wordpress.com/2016/04/21/luhendi-sql-haaldusest/

jpt. (juba inglisekeelsed) kohad.

Selgub, et Oracle andmebaasidega tegelevasse firmasse võib-olla ei saa tööle, kui hääldada “ess kju ell” (võid minna, järgmine), ja saab tööle, kui hääldad “siii-kju-ell”.

Sii - kju - ell on aga gurudele, kes juba emapiimaga on enesele sisse imenud päringute tegemise oskuse. Nii et võib-olla saate siiski vaid võimaluse Oracle gurudega veidi enam vestelda ja seejärel järgneb ikkagi “võite minna, järgmine”...

Mina hääldan praegu ikka veel ess - kju - ell ja ei oska ka prognoosida, kas üldse seda aega saabubki, kui saaks uhkelt häälida: “Sii - kju - ell”.

Mida aga see kolmetäheline meile ütleb?

Me teame, mida tähendab KGB - tähendas nuhkimist, praegu aga väga pikajalist, aga põhjalikku andmete kokkupakkimist.

Aga SQL?

Ärge kohe ütelge, et see on Structured Query Language. Selline “välisühendamine” selle mõistega poogiti SQL-le külge nimelt alles hiljem.

Skeemilt, mille ma kusagilt ära tirisin näete, et SQL omab mingit pistmist hulkade teooriaga, mida olete võib-olla juba lapsepõlves õppinud, sest mingil hetkel tuli matemaatika reformijatel pähe mõte matemaatika teha rangemaks ja juba lasteaias lastele selgeks õpetada aluste alused - hulgateooria koos valiku aksioomiga. (Sellest hulgateoreetilisest huumorist kunagi hiljem, praegu püsiksin teemas SQL).
Senini on SQL minu teada ainukene hulgateooria praktiline rakendus inimkonna ajaloos, täpsemalt hulgateooria see osis, mis tegeleb relatsioonidega.

Uskumatult palju inimesi arvab tänaseni, et relatsiooniline andmebaas tegeleb tabelitega, kus sõna relatsiooniline tähistab tabelite seostamist.

Tegelikult relatsioon on tabeli hulgateoreetiline sünonüüm. Nii et iga andmebaasisüsteem, mis tegeleb tabelitega (näiteks Excel) on ka selles mõttes “relatsiooniline”! 

Siin aga tulebki vahe sisse - tõeliselt relatsiooniline andmebaas tegeleb tabelitega ka sisuliselt, võttes oma töö aluseks mõne relatsioonilise päringukeele.

SQL on üks selline relatsiooniline päringukeel, selle juures mitte “päris” relatsiooniline.

EXCEL langeb sel juhul kohe konkurentsist, sest ta ei tegele tabelite vaheliste operatsioonidega sisuliselt. Kahe tabeli ühendamine on EXCEL-is üsna kohmakas ettevõtmine ja kõik see on EXCEL-isse külge poogitud hiljem.

Relatsiooniline päringukeel on selline programmeerimiskeel, mis kasutab tabelitega õiendamiseks relatsioonialgebra operatsioone. Õige relatsiooniline päringukeel tegelebki AINULT TABELITE või relatsioonidega.

Lühidalt äraseletatuna tähendab see seda, et tabelitest saadakse mingite operatsioonide toimel uued tabelid, millest omakorda rehkendatakse välja uued tabelid ja nii edasi. Kõik andmebaasitegevus taandub tabelitega rehkendamisele.

Nii nagu aritmeetika põhiobjektiks on arvud, on relatsiooniliste andmebaasisüsteemide põhiobjektideks tabelid ja uute tabelite moodustamise avaldised - SQL keele SELECT laused.

Uuendamine toimub INSERT ja UPDATE lausetega ja see ongi SQL kiirkursus 2-l real.

Nii tuleb relatsioonialgebra tõttu isegi igasugustest muudest suurustest (arvud, jooksev kuupäev etc...) teha SELECT lause abiga “tabel” 1x1, et saadud tulemustabelit saaks tabelialgebras kusagil edasi kasutada.
Võib-olla ilma

Dr. Edgar Frank Codd (August 23, 1923 – April 18, 2003) geeniuseta me sipleksime tänase päevani võrgu - või hierarhilistes andmebaasisüsteemides.

Relatsioonialgebra kasutuselevõtt on oma tähtsuselt võrdväärne funktsionaalse programmeerimise leiutamisega, s.t. LISP-ga. Ometi ei osata seda tänaseni hinnata. 

 Möödunud sajandi 90-ndatel aastatel üritas relatsioonilisi andmebaasisüsteeme (lühend RDMS) troonilt tõugata objektorienteeritus. Kirjutati manifeste ja loodi OO andmebaasisüsteeme. Tulemuseks on ikkagi see, et tänase päevani peavad koodinikerdajad ühest otsast kasutama OO keeli ja teises otsas istub endiselt kõigutamatult SQL andmebaasiserver, millega OO programmeerimine hästi ei oska suhelda. SQL elas manifestid üle ja jätkab võidukalt.

Mõni aeg tagasi tulid (ja tulevad edasi) andmebaaside turule uued produktid seeriast NoSQL.

Nagu arvata võiski, läheb aga “suurte andmete” (“big data”) mull tasapisi lõhki ja ... SQL jätkab endiselt.

NoSQL-i produktid aga on hakanud lisandama SQL oma “repertuaari”. Selliste andmebaasimootorite vastu aga ei ole SQL gurudel iialgi midagi olnud - miks mitte kasutada SQL -le lisaks mingeid keelekonstruktsioone veel, mis programmeerijate elu lihtsustaks? 

Kahjuks ei ole 70-ndatel loodud päringukeelt SQL ise suudetud uuendada. Sellest võiks sündida palju kasu. “Tõelised” päringukeeled senini on pigem akadeemilised mõtteharjutused.

Isiklikult olen veendunud, et reaalne andmebaasirevolutsioon toimub ainult läbi SQL keele uuendamise ja see seisab meil veel ees (ei ole tegelikult ühte SQL keelt, on erinevad dialektid ja nende paabel on omaette probleem).

Meie operatsioonisüsteemid (Windows, Unix) elavad veel SQL eelses ajastus - näiteks põhiobjektid, millega kasutaja ja programmeerijad opereerivad - on praegu paigutatud hierarhiliselt, puusüsteemis. Sama kehtib paljude teiste asjade kohta üldisemalt - programmeerijate mõttemallid - me paigutame oma objekte mõttes endiselt puukujulistesse hierarhiatesse...

Kuid sellest ehk kunagi hiljem, kui olen ennast SQL alastest teoreetilistest tellistest läbi närinud.

C.J.Date nimest ja kõigest, mida see mees on kirjutanud, ei saa te siinjuures ÜLE ega ÜMBER.

Sellega ma siin praegu tegelen - üritades tõestada endale, et teooria loeb.

Kogu mu 90-ndate aastate põgus programmeerimisekogemus (üks rahvastiku ja üks laoarvestussüsteem) põhines pooleldi nagu SQL süsteemil nimega FoxPro. Sisaldas nagu tabeleid, aga (algselt) SQL -i ei olnud.

Milleks üldse mingid keerulised SELECT laused? Võta tabel, kirjuta sinna midagi, siis võta teine tabel, seo neid kuidagi ja siis hakka nendega askeldama. See oli kohmakas, aga toimis, midagi sai teha ja SQL -i juurdepookimine tunduski üsna mõttetu.
Ühel hetkel aga tekkis süsteemi vajadus aruannete tegemise järele ja nüüd takkajärele mõistan, et minu poolt aretatud aruannete süsteem (mille üle isegi veidike uhke olen) tegi minu süsteemis neidsamu asju, mis oleks saanud kätte SQL lausetega palju, palju lihtsamini.

Meil Eestis endiselt peab hoiatama (isikliku kogemuse läbi, mitte mingi abstraktse teesina) jalgratta leiutamise maania eest.
Sageli nähakse ära hirmus vaev (näiteks mingite asjade andmebaasi kirjutamise asemel kirjutatakse oma tulemid mingisse tekstifaili ja siis põhiaeg tegeletakse sealt jälle sinna kirjutatud andmete välja otsimisega - tekstifailidega tegelemine on ju nii lihtne! ) samade asjade leiutamiseks, mis andmebaasisüsteemides on olnud ammu olemas.
Tänapäeval on olemas vabavaralised SQL andmebaasimootorid (MySQL, Firebird ntx) ja seetõttu raha taha ka asi pidama ei jää. Tõsi, mingi aeg tuleb kulutada, et vastav andmebaasiline mõttelaad omandada.
Mina aga tollal “päris” SQL-ini ei jõudnudki - enne jõudis minu süsteemi kasutav firma ennast ära müüa soomlastele. Oma auks pean ütlema, et mul programmis juba oli pesa, kus sai SQL lausetega toimetada.

Nüüd siis umbes 15 aastat hiljem jälle sama (reha? ) süsteemi otsas.