Mūsdienās strukturētā vaicājumu valoda ir standarta veids, kā manipulēt ar datiem un veikt vaicājumus relāciju datu bāzēs, lai gan starp produktiem ir arī patentēti paplašinājumi. SQL vienkāršība un visuresamība pat daudzu “NoSQL” vai ar relāciju nesaistītu datu krājumu, piemēram, Hadoop, radītājus ir pamudinājusi pieņemt SQL apakškopas vai nākt klajā ar savām SQL veida vaicājumu valodām.
Bet SQL ne vienmēr bija “universālā” valoda relāciju datu bāzēm. Kopš sākuma (ap 1980. gadu) SQL pret to bija noteikti streiki. Daudzi toreizējie pētnieki un izstrādātāji, ieskaitot mani, domāja, ka SQL papildu izdevumi neļaus to praktiski izmantot ražošanas datu bāzē.
Skaidrs, ka mēs kļūdījāmies. Bet daudzi joprojām uzskata, ka visu SQL ērtības un pieejamības dēļ izpildlaika veiktspējā pieprasītā cena bieži ir pārāk augsta.
SQL vēsture
Pirms bija SQL, datu bāzēm bija saspringtas, navigācijas programmēšanas saskarnes, un tās parasti tika veidotas ap tīkla shēmu, ko sauc par CODASYL datu modeli. CODASYL (Datu sistēmu valodu komiteja) bija konsorcijs, kas bija atbildīgs par COBOL programmēšanas valodu (sākot ar 1959. gadu) un datu bāzes valodu paplašināšanu (sākot ar 10 gadiem vēlāk).
Kad jūs programmējāt CODASYL datu bāzi, jūs virzījāties uz ierakstiem, izmantojot kopas, kas izsaka attiecības viens pret daudziem. Vecākas hierarhiskas datu bāzes ļauj ierakstam piederēt tikai vienai kopai. Tīkla datu bāzes ļauj ierakstam piederēt vairākām kopām.
Pieņemsim, ka vēlaties uzskaitīt studentus, kas uzņemti CS 101. Vispirms jūs atradīsit "CS 101" iekš Kursi iestatiet pēc nosaukuma, iestatiet to kā Reģistrētie komplekts, atrodiet pirmo dalībnieku (ffm) no Reģistrētie komplekts, kas ir a Students ierakstiet un uzskaitiet to. Tad jūs nonāktu ciklā: atrodiet nākamo dalībnieku (fnm) un uzskaitiet to. Kad fnm neizdevās, jūs izietu no cilpas.
Tas datubāzes programmētājam var šķist daudz pārmeklēšanas, taču izpildes laikā tas bija ļoti efektīvs. Eksperti, piemēram, Maikls Stounbrakers no Kalifornijas Universitātes Bērklijā un Ingress, norādīja, ka šāda veida vaicājumu veikšana CODASYL datu bāzē, piemēram, IDMS, prasīja aptuveni pusi no centrālā procesora laika un mazāk nekā pusi atmiņas kā tas pats vaicājums relāciju datu bāzē, izmantojot SQL .
Salīdzinājumam, ekvivalents SQL vaicājums, lai atgrieztu visus CS 101 studentus, būtu kaut kas līdzīgs
Atlasiet studentu.nosaukumu no kursiem, uzņemtajiem, studentiem, KUR kursa nosaukums
Šī sintakse nozīmē relāciju iekšējo savienojumu (faktiski divus no tiem), kā es paskaidrošu tālāk, un atstāj dažas svarīgas detaļas, piemēram, savienojumiem izmantotos laukus.
Relāciju datu bāzes un SQL
Kāpēc jūs atteiktos no diviem izpildes ātruma un atmiņas izmantošanas uzlabojuma faktoriem? Tam bija divi lieli iemesli: izstrādes vienkāršība un pārnesamība. Es nedomāju, ka 1980. gadā vienam no tiem bija liela nozīme salīdzinājumā ar veiktspēju un atmiņu, taču, uzlabojoties un kļūstot lētākai datortehnikai, cilvēki vairs nerūpējās par izpildes ātrumu un atmiņu un vairāk uztraucās par izstrādes izmaksām.
Citiem vārdiem sakot, Mūra likums nogalināja CODASYL datu bāzes par labu relāciju datu bāzēm. Kā tas notika, izstrādes laika uzlabojums bija ievērojams, bet SQL pārnesamība izrādījās sapnis.
Kur radies relāciju modelis un SQL? EF “Ted” Codd bija IBM Sanhosē pētījumu laboratorijas datorzinātnieks, kurš 1960. gados izstrādāja relāciju modeļa teoriju un publicēja to 1970. gadā. IBM bija lēna, lai ieviestu relāciju datu bāzi, cenšoties aizsargāt tās CODASYL datu bāze IMS / DB. Kad IBM beidzot uzsāka savu System R projektu, izstrādes komanda (Dons Čemberlins un Rejs Boiss) nebija Codd pakļautībā, un viņi ignorēja Codd 1971. gada relāciju valodas darbu Alpha, lai izveidotu savu valodu SEQUEL (strukturētā angļu vaicājuma valoda). 1979. gadā, vēl pirms IBM bija pat izlaidis savu produktu, Lerijs Elisons iekļāva valodu savā Oracle datu bāzē (kā specifikāciju izmantojot IBM SEQUEL publikācijas pirms palaišanas). SEQUEL drīz kļuva par SQL, lai izvairītos no starptautiskas preču zīmes pārkāpumiem.
“Tom-toms pukstēšana SQL” (kā izteicās Maikls Stounbrakers) nāca ne tikai no Oracle un IBM, bet arī no klientiem. Nebija viegli pieņemt darbā vai apmācīt CODASYL datubāzu izstrādātājus un programmētājus, tāpēc SEQUEL (un SQL) izskatījās daudz pievilcīgāki. SQL 1980. gadu beigās bija tik pievilcīgs, ka daudzi datu bāzu pārdevēji būtībā sasēja SQL vaicājumu procesoru virs savām CODASYL datubāzēm, par lielu Codd satraukumu, kurš uzskatīja, ka relāciju datu bāzes ir jāveido no jauna, lai tās būtu relācijas.
Tīra relāciju datu bāze, ko izstrādājis Codd, ir veidota uz grupām, kas sagrupētas attiecībās, kas atbilst pirmās kārtas predikātu loģikai. Reālās pasaules relāciju datu bāzēs ir tabulas, kas satur laukus, ierobežojumus un aktivizētājus, un tabulas ir saistītas, izmantojot svešas atslēgas. SQL tiek izmantots, lai deklarētu atgriežamos datus, un SQL vaicājumu procesors un vaicājumu optimizētājs pārvērš SQL deklarāciju par vaicājuma plānu, kuru izpilda datu bāzes dzinējs.
SQL ietver apakšvalodu shēmu definēšanai, datu definēšanas valodu (DDL), kā arī apakšvalodu datu modificēšanai - datu manipulācijas valodu (DML). Abiem šiem saknēm ir agrīnas CODASYL specifikācijas. Trešā SQL apakšvaloda deklarē vaicājumus, izmantojot SELECT paziņojums un relāciju savienojumi.
SQLSELECT paziņojums, apgalvojums
The SELECT paziņojums vaicājuma optimizētājam norāda, kādus datus atgriezt, kādās tabulās meklēt, kādas attiecības ievērot un kādu kārtību uzlikt atgrieztajiem datiem. Vaicājumu optimizatoram pašam jāizdomā, kādus indeksus izmantot, lai izvairītos no rupja spēka tabulu skenēšanas un panāktu labu vaicājumu veiktspēju, ja vien konkrētā datu bāze neatbalsta rādītāju ieteikumus.
Daļa relāciju datu bāzes dizaina mākslas ir atkarīga no apdomīgas indeksu izmantošanas. Ja biežam vaicājumam izlaižat rādītāju, visa datu bāze var palēnināties, ja tiek lasītas lielas slodzes. Ja jums ir pārāk daudz indeksu, visa datu bāze var palēnināties smagas rakstīšanas un atjaunināšanas slodzes laikā.
Vēl viena svarīga māksla ir izvēlēties labu, unikālu primāro atslēgu katram galdam. Jums ne tikai jāņem vērā primārās atslēgas ietekme uz izplatītiem vaicājumiem, bet arī tas, kā tā darbosies pievienošanās reizēs, kad citā tabulā tā tiks parādīta kā sveša atslēga, un kā tā ietekmēs datu atsauces vietu.
Izvērstā gadījumā, ja datu bāzes tabulas tiek sadalītas dažādos apjomos atkarībā no primārās atslēgas vērtības, ko sauc par horizontālo šķembu, jums jāapsver arī tas, kā primārā atslēga ietekmēs skaidošanu. Padoms. Jūs vēlaties, lai tabula vienmērīgi tiktu sadalīta pa sējumiem, kas liek domāt, ka nevēlaties kā primārās atslēgas izmantot datuma zīmogus vai secīgus veselus skaitļus.
Diskusijas par SELECT paziņojums var sākties vienkārši, bet var ātri kļūt mulsinošs. Apsveriet:
SELECT * NO klientiem;
Vienkārši, vai ne? Tajā tiek prasīti visi lauki un visas rindas Klienti tabula. Pieņemsim, ka tomēr Klienti tabulā ir simts miljoni rindu un simts lauku, un viens no laukiem ir liels teksta lauks komentāriem. Cik ilgs laiks būs visu šo datu noņemšana, izmantojot tīkla savienojumu ar 10 megabitu sekundē, ja katrā rindā ir vidēji 1 kilobaits datu?
Varbūt jums vajadzētu samazināt, cik daudz jūs sūtāt pa vadu. Apsveriet:
ATLASIET TOP 100 uzņēmuma nosaukumu, pēdējoSaleDate, lastSaleAmount, totalSalesAmount FROM klientusKUR štats UN pilsēta
PASŪTĪT PĒC lastSaleDate Dilstošā secībā;
Tagad jūs izvēlēsieties daudz mazāk datu. Jūs esat lūdzis, lai datu bāze jums piešķir tikai četrus laukus, ņem vērā tikai Klīvlendas uzņēmumus un sniedz tikai 100 uzņēmumus ar visjaunākajiem pārdošanas apjomiem. Lai to izdarītu visefektīvāk datu bāzes serverī, tomēr Klienti tabulai ir nepieciešams indekss valsts + pilsēta priekš KUR klauzula un rādītājs lastSaleDate priekš SAKĀRTOT PĒC un TOP 100 klauzulas.
Starp citu, TOP 100 ir derīgs SQL Server un SQL Azure, bet ne MySQL vai Oracle. MySQL izmantosiet 100. LIMITS pēc tam, kad KUR klauzula. Oracle izmantosiet iesietu ROWNUM kā daļu no KUR klauzula, t.i. KUR ... UN ROWNUM <= 100. Diemžēl ANSI / ISO SQL standarti (un līdz šim ir deviņi no tiem, kas stiepjas no 1986. gada līdz 2016. gadam) iet tikai tik tālu, aiz kura katra datu bāze ievieš savas patentētās klauzulas un funkcijas.
Pievienojas SQL
Līdz šim esmu aprakstījis SELECT sintakse atsevišķām tabulām. Pirms es paskaidrojuPIEVIENOTIES klauzulas, jums ir jāsaprot svešās atslēgas un sakarības starp tabulām. Es to paskaidrošu, izmantojot piemērus DDL, izmantojot SQL Server sintaksi.
Īsā versija ir diezgan vienkārša. Katrai tabulai, kuru vēlaties izmantot attiecībās, ir jābūt galvenajam atslēgas ierobežojumam; tas var būt vai nu viens lauks, vai arī lauku kombinācija, ko definē izteiksme. Piemēram:
IZVEIDOT GALDA Personas (PersonID int NAV VISPĀRĒJAIS ATSLĒGS,
PersonName char (80),
...
Katra tabula, kurai ir jāattiecas Personas jābūt laukam, kas atbilst Personas primāro atslēgu un lai saglabātu relāciju integritāti, šajā laukā ir jābūt svešas atslēgas ierobežojumam. Piemēram:
IZVEIDOT GALDA Rīkojumus (OrderID int NULL PRIMARY Key,
...
PersonID int ĀRVALSTA GALVENĀS ATSAUCES Personas (PersonID)
);
Abiem apgalvojumiem ir garākas versijas, kurās tiek izmantots SAVIENOJUMS atslēgvārds, kas ļauj nosaukt ierobežojumu. Tas ir tas, ko ģenerē lielākā daļa datu bāzes noformēšanas rīku.
Primārās atslēgas vienmēr ir indeksētas un unikālas (lauka vērtības nevar dublēt). Citus laukus pēc izvēles var indeksēt. Bieži ir lietderīgi izveidot indeksus ārvalstu atslēgu laukiem un laukiem, kas parādās KUR un SAKĀRTOT PĒC kaut arī ne vienmēr, jo rakstīšanas un atjaunināšanas iespējamās izmaksas ir lielākas.
Kā jūs rakstāt vaicājumu, kas atgriež visus Džona Doe pasūtījumus?
Atlasiet PersonName, OrderID FROM PersonsINNER JOIN Pasūtījumi personām. PersonasID = Pasūtījumi. PersonID
WHERE PersonName;
Patiesībā ir četri veidi PIEVIENOTIES: IEKŠĒJA, ĀRĒJĀ, Kreisais, un PA LABI. The IEKŠĒJAIS PIEVIENOŠANĀS ir noklusējums (jūs varat izlaist vārdu IEKŠĒJA), un tajā ir iekļautas tikai rindas, kurās abās tabulās ir atbilstošas vērtības. Ja vēlaties uzskaitīt personas neatkarīgi no tā, vai viņiem ir pasūtījumi, izmantojiet a PALIEK PIEVIENOTIES, piemēram:
Atlasiet PersonName, OrderID FROM PersonsLEFT JOIN Pasūtījumi personām. PersonasID = Pasūtījumi. PersonID
PASŪTĪT PĒC PersonName;
Kad sākat veikt vaicājumus, kas savieno vairāk nekā divas tabulas, kuros tiek izmantotas izteiksmes vai kas piespiest datu tipus, sintakse sākumā var kļūt nedaudz mataina. Par laimi ir datu bāzes izstrādes rīki, kas var ģenerēt pareizus SQL vaicājumus, bieži velkot un nometot tabulas un laukus no shēmas diagrammas vaicājumu diagrammā.
SQL saglabātās procedūras
Dažreiz programmas deklaratīvais raksturs SELECT paziņojums nenonāk jūs tur, kur vēlaties doties. Lielākajai daļai datu bāzu ir iespēja, ko sauc par glabātajām procedūrām; diemžēl šī ir joma, kurā gandrīz visās datubāzēs tiek izmantoti ANSI / ISO SQL standartu patentēti paplašinājumi.
SQL Server sākotnējais saglabāto procedūru (vai saglabāto procesu) dialekts bija Transact-SQL, jeb T-SQL; Oracle tas bija PL-SQL. Abās datu bāzēs ir pievienotas papildu valodas saglabātajām procedūrām, piemēram, C #, Java un R. Vienkārša T-SQL glabāta procedūra var būt tikai parametru versija SELECT paziņojums, apgalvojums. Tās priekšrocības ir lietošanas ērtums un efektivitāte. Saglabātās procedūras tiek optimizētas, kad tās tiek saglabātas, nevis katru reizi, kad tās tiek izpildītas.
Sarežģītākā T-SQL glabātā procedūra var izmantot vairākus SQL priekšrakstus, ievades un izvades parametrus, lokālos mainīgos, SĀKT ... BEIGT bloki, JA ... TAD ... VĒL nosacījumi, kursori (kopas apstrāde pa rindai), izteicieni, pagaidu tabulas un vesela virkne citas procesuālās sintakses. Acīmredzot, ja saglabātā procedūras valoda ir C #, Java vai R, jūs izmantosiet šo procesuālo valodu funkcijas un sintaksi. Citiem vārdiem sakot, neskatoties uz to, ka SQL motivācija bija izmantot standartizētus deklaratīvos vaicājumus, reālajā pasaulē jūs redzat daudz datu bāzes specifisku procesuālo serveru programmēšanas.
Tas mūs gluži neatgriežas CODASYL datubāzes programmēšanas vecajos laikos (lai gan kursori ir tuvu), taču tas iet atpakaļ no idejām, ka SQL priekšraksti ir jāstandartizē un ka bažas par veiktspēju jāatstāj datu bāzes vaicājumu optimizētāja ziņā . Galu galā snieguma dubultošana bieži ir pārāk liela, lai to atstātu uz galda.
Uzziniet SQL
Turpmāk uzskaitītās vietnes var palīdzēt jums iemācīties SQL vai atklāt dažādu SQL dialektu dīvainības.
