Könyvünk témája az ügyfél kiszolgáló alapú SQL rendszerek hangolása. De mit is jelent mindez?

1 Facilis Descensus Averni1 Könyvünk témája az ügyfél–kiszolgáló alapú SQL rendszerek hangolása. De mit is jelent mindez? Hangolás alatt sebességnövelést értünk. Van némi különbség a hangolás és az optimalizálás (hatékonyságnövelés) között; hangolás az, amit egy adatbázissal teszünk (például a gyorsítótár méretének megváltoztatása, újrafelosztás, indexek újjáépítése), míg az optimalizálást egy programon végezzük (például listák egyszerûsítése, már meglévõ erõforrások kihasználása, a programkód átírása). Könyvünkben azonban eltekintünk e finom jelentésbeli különbségtõl. A sebesség szó két dologra vonatkozhat: a válaszidõre (response time, mennyi idõbe kerül egy utasítás végrehajtása), és a munkateljesítményre (throughput, adott idõegység alatt hány mûveletet tud végrehajtani a DBMS). A továbbiakban fõként ez utóbbival foglalkozunk. Az SQL a DBMS-megvalósítások (DBMS: Database Management System, adatbázis-kezelõ rendszer) által támogatott nyelv. Szándékosan használjuk az általános elnevezést, hogy egyértelmû legyen: nem konkrét termékrõl van szó; könyvünk azzal foglalkozik, ami az összes jelentõs fejlesztésben közös. Valójában mindegyik ugyanazon szabványos mag köré épül, így konkrét tanácsokat adhatunk anélkül, hogy egyikre vagy másikra „szakosodnánk”. Ahol sok eltérés van a DBMS-ek között, ott egy táblázatban felvázoljuk ezeket. Ahol a különbség kevés, ott ismertetjük az általános esetet, és a lap szélén kiemeljük a kivételeket. Programot valamilyen programozási nyelven írunk, mint az SQL, a C, vagy a Java. Ne számítsunk tehát hosszas leírásokra az eszközök kiválasztásáról, a telepítésnél beállítandó jelzõbitekrõl, vagy arról, mely segédprogramok alkalmasak a felhasználók felügyeletére. Ezek a kérdések az adatgazda (DBA, Database Administrator, adatbázis-rendszergazda) 1

Szó szerint: „pokolra szállni könnyû”…csak kijutni nehéz! (Vergilius nyomán)

2

SQL teljesítményfokozás

feladatkörébe tartoznak. Tisztában vagyunk vele, hogy könyvünk számos fejezete az adatgazdák számára is érdekes lehet, ahogy azt is tudjuk, hogy legtöbb olvasónk egyszerre adatgazda és programozó, csupán egy dolgot szeretnénk világossá tenni: e könyv azokhoz szól, akik a programokat írják.

A téma jelentõs „Tapasztalataink szerint (és ebben számos szakember egyetért) az SQL-kiszolgálókon elért teljesítménynövekedés 80 százaléka az SQL forráskódon tett javításokból származik, nem pedig a beállítások ravasz átszervezésébõl vagy az operációs rendszer állítgatásából.” – Kevin Kline és mások, Transact-SQL Programming, O'Reilly & Associates „A gyakorlat azt mutatja, hogy az összes hangolás 80-90 százaléka nem adatbázisszinten, hanem felhasználói szinten történik.” – Thomas Kyte, Expert One on One: Oracle, Wrox Press

Bármely DBMS teljesítményét növelhetjük, feltéve, hogy megfelelõképpen járunk el. A teljesítmény növelésére számtalan lehetõség van: • Ne tegyünk olyan elemeket SQL-utasításainkba, amelyek köztudottan csökkentik a hatékonyságot. • Értsük meg, hogyan épül fel egy szokványos adatbázis. • Ne képzeletbeli, hanem valós problémák megoldására törekedjünk. Vegyünk egy egyszerû példát. Tegyük fel, hogy az alábbi SQL-utasításról van szó: SELECT column1 From Table1 WHERE column1 = 77

Egy ilyen utasításnál, úgy gondoljuk, a fõ kérdés a következõ: kell-e a column1-re index? Egy egész fejezetet az indexeknek szenteltünk; hogyan néznek ki, milyen változatok léteznek, hogyan befolyásolják az adatok módosítását, és így tovább. Egy másik fejezetben az EXPLAIN utasítással (illetve annak megfelelõjével) foglalkozunk, nevezetesen: hogyan tudhatjuk meg segítségével, hogy az adott DBMS ténylegesen használ-e indexeket az adott SELECT utasításhoz. Ez jól tükrözi a fontossági sorrendet; listánkon az elsõ helyen az indexek, s így az elméleti kérdések szerepelnek. Természetesen nem hanyagolhatjuk el a gyakorlati oldalt sem, így a hibakeresõ eszközökkel is kiemelten foglalkozunk. Reméljük, hogy az elméleti ismeretek birtokában hamar elérhetõ lesz a kívánt cél. A könyvben említett ötleteket nem tanácsos elõzetes tesztelés nélkül alkalmazni, ötlet híján viszont csak véletlenszerûen csaponganánk egyik tervtõl a másikig anélkül, hogy a végén biztosak lehetnénk benne, hogy valóban a legjobb megoldást választottuk.

1. fejezet • Facilis Descensus Averni Véleményünk szerint egy ötlet akkor mondható jónak, ha a DBMS-ek többségében legalább 5%-kal javítja a teljesítményt. Ez szerény célkitûzésnek tûnik, de gondoljunk csak bele: elõször is, mindig meg kell gyõzõdnünk róla, hogy ötletünk nem rontja-e valamely másik DBMS teljesítményét – szerintünk egy ötlet csak akkor jó, ha általánosan alkalmazható; másrészt még az oly kevésnek tûnõ 5% is sokat számít olyan esetekben, ahol egy mûvelet sokszor, sok sorra hajtódik végre; harmadszor, a könyvet csupán egyszer kell elolvasni, ugyanis ha egyszer elsajátítottuk az ismereteket, utána már minimális erõfeszítéssel éveken keresztül használhatjuk; negyedrészt, a teljesítmény-növekedés gyakran az 5% többszörösét is eléri; ötödrészt pedig ne feledjük: az elért hatások – bár csekélynek tûnnek – halmozottan fognak érvényesülni. Azt is reméljük továbbá, hogy a téma érdekesnek bizonyul. Az adatbázisokkal foglalkozó szakemberek közül soknál, és a jobbak közül mindegyiknél a következõ két kérdés áll a középpontban: „Hogyan mûködik?” és „Hogyan kellene mûködnie?”.

„A Nyolcak” „Elméletileg nincs különbség elmélet és gyakorlat között. Gyakorlatilag azonban van.” – Jan L.A. van de Snepscheut

Nem szükséges bizonyos területekre szakosodnunk ahhoz, hogy a könyvbõl hasznos ötleteket merítsünk. Vizsgálódásunk során újra meg újra azzal szembesülünk, hogy az egyik DBMS-re érvényes alapvetõ állítások ugyanúgy érvényesek a többi DBMS-re is. Például kijelenthetjük, hogy „a DBMS-ek rögzített méretû lapokon tárolják az adatokat, és a lapok mérete a kettõ valamely hatványa”. De nem túl merész ez az általánosítás? Legyünk õszinték: ezt a megállapítást nem ellenõriztük az összes létezõ DBMS esetében, tudjuk, hogy nem természeti törvényszerûség, sõt, legalább két olyan DBMS-rõl tudunk, melyekre az állítás nem érvényes. Könyvünkben azonban ha „az összes DBMS”-rõl, vagy egyszerûen „DBMS-ekrõl” állítunk valamit, akkor nem ködösítésrõl vagy általánosításról van szó; egészen pontosan nyolc konkrét DBMS-re gondolunk, melyeket valóban ellenõriztünk, és amelyekre vonatkozóan a könyv írásakor a megállapítások garantáltan érvényesek. Ezen DBMS-eket „A Nyolcak” néven fogjuk emlegetni, ami ugyan nem hivatalos kifejezés, viszont alkalmas arra, hogy emlékeztessen erre a bevezetésre. A Nyolcak tagjait a következõ feltételek alapján válogattuk ki: • Az adott DBMS legyen ügyfél–kiszolgáló alapú SQL DBMS. Az ettõl eltérõ típusú DBMS-eket kizártuk. • A DBMS – nyilvános és ellenõrizhetõ felmérések szerint – rendelkezzék legalább 1 százalékos piaci részesedéssel az észak-amerikai és európai piacon, vagy legyen széles körben ismert nyílt forráskódú rendszer.

3

4


• A DBMS támogassa a JDBC-t (Java Database Connectivity) és az ODBC-t (Open Database Connectivity). Szeretnénk hangsúlyozni, hogy egyik DBMS sem a minõsége alapján került listánkra. A Nyolcakat csakis az alapján állítottuk össze, mekkora valószínûséggel fog az olvasó találkozni az adott DBMS-sel, vagy valami hozzá nagyon hasonlóval. Mivel A Nyolcak összes piaci részesedése több, mint 85%, és közülük a nyílt forráskódú DBMS-eket már száz- meg százezerszer töltötték le az Internetrõl, biztosak lehetünk benne, hogy az esetek legalább 90 százalékában A Nyolcak egyikével lesz dolgunk. Az általunk tesztelt DBMS-ek az 1.1. táblázatban láthatók. Amikor anyagot gyûjtöttünk könyvünkhöz, az összes DBMS-nek azt az akkori legújabb változatát telepítettük, amely rendelkezésre állt MS Windows NT operációs rendszerre. A DBMS-eket a gyártók javaslata szerinti alapértelmezett rendszerekkel telepítettük és teszteltük, kivéve, ahol ezt másképp jelöltük a következõ részben (Telepítési beállítások). Egyes esetekben ingyenes próbaváltozatot vagy személyi kiadást (personal edition) használtunk, viszont sohasem teszteltünk többletköltséggel járó, vagy ritkán alkalmazott beállításokkal – igyekeztünk mellõzni az alapértelmezettõl eltérõ telepítési beállításokat és kapcsolókat. 1.1. táblázat A Nyolcak

Rövid név IBM Informix Ingres InterBase

Microsoft MySQL Oracle Sybase

Terméknév és változat Megjegyzés IBM DB2 Universal Database 7.2 IBM Informix Dynamic Server 9.3 Ma már az IBM tulajdona. Ingres II 2.5 A Computer Associates International tulajdona. InterBase 6.0 Nyílt forráskódú változat. A Borland Software Corporation tulajdona. Microsoft SQL Server 2000 MySQL 3.23 Nyílt forráskódú. A MySQL AB tulajdona. Oracle 9i Sybase ACE 12.5

A gyártók közül egyiket sem szeretnénk elõnyben részesíteni vagy bírálni, mivel célunk a már meglévõ SQL rendszerek feljavítása. A könyv tartalmaz ugyan teszteredményeket, de nem adtunk meg teljesítményre vonatkozó abszolút érvényû adatokat, és különbözõ DBMS-ek összehasonlító elemzéseit sem közöltük. Ennek két oka van. Az egyik ok nyilvánvaló: efféle adatok közlése nem illene

1. fejezet • Facilis Descensus Averni össze eredeti célkitûzésünkkel. A másik ok már érdekesebb: A Nyolcak közül három – az Informix, a Microsoft, és az Oracle – olyan felhasználói engedéllyel rendelkezik, amely kifejezetten megtiltja a teljesítményelemzések közzétételét.

Telepítési beállítások Ahogy korábban említettük, A Nyolcakat a gyártók javaslata szerinti alapértelmezett rendszerekkel telepítettük. Ezzel mellõzni kívántuk a többletköltséggel járó, illetve ritkán alkalmazott beállításokat, valamint megpróbáltuk elegyengetni a terepet a különbözõ DBMS-ek között. Kivételt képeztek az alábbi esetek: • A következetesség érdekében minden DBMS esetében – ahol lehetséges volt – ugyanazon karakterkészlettel, a Windows 1252-es kódlappal végeztük tesztjeinket. Azért döntöttünk emellett, mert a tesztelést Windows NT rendszeren végeztük, és ki akartuk használni a nemzetközi karakterkészlet lehetõségeit. • Ahol lehetséges volt, teszteltük a különbözõ DBMS-ekben végzett szótári és bináris rendezések közti eltéréseket. Az IBM esetében ennek megfelelõen az adatbázist az alapértelmezett IBM-1252 karakterkészlettel, valamint az alapértelmezett Local Alphabet (helyi ábécé) szótári rendezési sorrenddel hoztuk létre. A szótári rendezések teszteléséhez CHAR oszlopokat használtunk, a bináris rendezésekhez pedig CHAR FOR BIT DATA oszlopokat. Az IBM nem rendelkezik az SQL szabványnak megfelelõ CHARACTER SET vagy COLLATE beállítással. Az Informix esetében az ügyfélre és a kiszolgálóra is az alapértelmezett EN_US 8859-1 helyi nyelvi beállítást (locale) telepítettük, valamint az alapértelmezésen kívüli EN_GB.88591 db_locale beállítást, amely szótári rendezési sorrendet biztosít NCHAR típusú oszlopok számára.A szótári rendezéseket NCHAR oszlopokkal teszteltük, a bináris rendezéseket pedig CHAR oszlopokkal. Az Informix sem rendelkezik az SQL szabványnak megfelelõ CHARACTER SET vagy COLLATE beállítással. Az Ingres adatbázist az alapértelmezett WIN1252 karakterkészlettel és a nem alapértelmezett „lmulti” szótári rendezési sorrenddel hoztuk létre. CHAR oszlopokkal teszteltük a szótári rendezéseket, BYTE oszlopokkal a bináris rendezéseket. Az Ingres sem rendelkezik az SQL szabványnak megfelelõ CHARACTER SET vagy COLLATE beállítással. Az InterBase esetében a DEFAULT CHARACTER SET WIN1252 karakterkészlettel hoztuk létre az adatbázist. A szótári rendezések tesztelését NCHAR oszlopokkal végeztük a COLLATE EN_US jelsorrenddel, a bináris rendezéseket pedig NCHAR oszlopokkal és COLLATE beállítás nélkül teszteltük. NCHAR oszlopokat használtunk a következõ esetekben: (a) COLLATE DA_DA jelsorrenddel a dán és norvég nyelvû rendezések teszteléséhez, (b) COLLATE DE_DE jelsorrenddel a német nyelvû rendezések teszteléséhez, (c) az izlandi rendezésekhez, COLLATE IS_IS jelsorrenddel, (d) COLLATE EN_UK jelsorrenddel

5

6


az ír nyelvû rendezések tesztelésénél, (e) a spanyol nyelvû rendezések tesztelésénél, COLLATE ES_ES jelsorrenddel, és (f) COLLATE FI_FI és COLLATE SV_SV jelsorrenddel a finn, illetve svéd nyelvû rendezések tesztelésénél. A Microsoft esetében az alapértelmezett 1252/ISO karakterkészlettel telepítettük az SQL Server rendszert. A CHAR oszlopok esetében az alapértelmezett Dictionary Order, case insensitive (kis- és nagybetûket nem megkülönböztetõ szótári rendezés) rendezési sorrendet, valamint a nem alapértelmezett „Binary” Unicode-jelsorrendet használtunk. A szótári rendezések teszteléséhez CHAR oszlopokat használtunk COLLATE beállítás nélkül, a bináris rendezések teszteléséhez pedig CHAR oszlopokat COLLATE SQL_Latin1_General_BIN jelsorrenddel. CHAR oszlopokat használtunk továbbá az alábbi esetekben: (a) COLLATE SQL_Danish jelsorrenddel a dán és norvég nyelvû rendezések teszteléséhez, (b) COLLATE German_Phonebook jelsorrenddel a német nyelvû telefonkönyvi rendezések teszteléséhez, (c) az izlandi rendezések tesztelésénél, COLLATE SQL_Icelandic jelsorrenddel, (d) COLLATE Mexican_Trad_Spanish, illetve COLLATE Modern_Spanish jelsorrenddel a spanyol nyelvû rendezések tesztelésénél, és (e) COLLATE SQL_SwedishStd jelsorrenddel a svéd és finn nyelvû rendezések teszteléséhez. (Megjegyzés: ahol lehetséges volt, a következõ beállításokat használtuk: PREF kapcsoló, 1252-es kódlap, kis- és nagybetûk megkülönböztetése kikapcsolva (CI), ékezetfigyelés (AS) bekapcsolva.) A MySQL esetében az alapértelmezett Latin1 (más néven iso_1) karakterkészlettel telepítettük a rendszert. CHAR oszlopokkal teszteltük a szótári rendezéseket, a bináris rendezéseket pedig CHAR BINARY oszlopokkal. A MySQL nem rendelkezik az SQL szabványnak megfelelõ CHARACTER SET vagy COLLATE beállítással. Az Oracle esetében a feltételekhez igazodva az alapértelmezett WIN1252 karakterkészlettel telepítettük a rendszert. A szótári rendezések teszteléséhez CHAR oszlopokat használtunk és az NLS_SORT=XWEST_EUROPEAN beállítást, a bináris rendezések teszteléséhez pedig CHAR oszlopokat és az NLS_SORT=BINARY beállítást. CHAR oszlopokat használtunk továbbá a következõ esetekben: (a) a dán és norvég nyelvû rendezések teszteléséhez, NLS_SORT=DANISH és NLS_SORT=NORWEGIAN jelsorrenddel, (b) NLS_SORT=XGERMAN jelsorrenddel a német nyelvû szótári rendezések teszteléséhez, (c) NLS_SORT=GERMAN_DIN jelsorrenddel a német nyelvû telefonkönyvi rendezések teszteléséhez, (d) az izlandi nyelvû rendezések teszteléséhez, NLS_SORT=ICELANDIC jelsorrenddel, (e) NLS_SORT= XWEST_EUROPEAN jelsorrenddel az ír nyelvû rendezések teszteléséhez, (f) NLS_SORT=XSPANISH jelsorrenddel a hagyományos spanyol (Spanish Traditional) rendezések teszteléséhez, (g) NLS_SORT=SPANISH jelsorrenddel a modern spanyol (Spanish Modern) rendezések teszteléséhez, és (h) NLS_SORT=FINNISH jelsorrenddel a svéd és finn nyelvû rendezések teszteléséhez. A Sybase esetében a Character Set=iso_1 karakterkészlettel, valamint a Sort Order=Dictionary rendezési sorrenddel telepítettük a rendszert (mindkét beállítás eltér az alapértelme-

1. fejezet • Facilis Descensus Averni zettõl). A szótári rendezések teszteléséhez CHAR oszlopokat használtunk, a bináris rendezések teszteléséhez pedig BINARY oszlopokat. A Sybase sem rendelkezik az SQL szabványnak megfelelõ CHARACTER SET vagy COLLATE beállítással.

A teszteredményekrõl A könyvben sokszor találkozunk A Nyolcakon futtatott tesztek kódjaival. Minden példa második utasításához tartozik egy ELÕNY: x/8 alakú megjegyzés. Ez az arányszám rendkívül lényeges; azt jelzi, hogy A Nyolcak közül hány rendszer fut gyorsabban, ha a második példában bemutatott, javított formában valósítjuk meg az adott SQL-utasítást. Adott DBMS esetében akkor jeleztünk javulást, ha a teljesítmény legalább 5 százalékkal növekedett. Természetesen a változás mértéke más és más lesz különbözõ adatok és különbözõ gépek esetén. Itt csupán az általunk elvégzett tesztek eredményeit közöljük. Az ELÕNY:0/8 jelzés azt jelenti, hogy idõpocsékolás lenne optimális formára alakítani az adott SQL-utasítást, mert a DBMS úgyis megteszi ezt helyettünk. Az ELÕNY:4/8 jelzés viszont azt jelenti, hogy A Nyolcak fele jobban teljesített a javasolt forma alkalmazása esetén, míg a másik fele mindkét utasításformánál ugyanolyan jól teljesített. Még akkor is jobban járnunk a feljavított utasításformával, ha a teljesítmény-növekedés aránya csak 1/8 (azaz A Nyolcak közül csupán egy rendszer teljesítménye javult a második alak alkalmazásával), mivel az esetek egy részében ezzel javulna a teljesítmény, míg a többi esetben nem romlana. Javaslataink tehát soha nem lesznek káros hatással A Nyolcak egyikére sem – egy kivétellel, ami pedig a következõ: Néhány esetben a második alak alkalmazásakor az egyik DBMS abnormálisan viselkedett és teljesítménye romlott, míg a többi rendszer jelentõs teljesítményjavulást mutatott. Ilyen esetekben úgy gondoltuk, érdemes legalább megemlíteni az optimalizálás lehetõségét. A kivételeknél mindig feltüntettük, mely DBMS-ben nem érdemes a javított formát használni. A teszteket egyprocesszoros Windows NT gépen futtattuk, úgy, hogy ezalatt más feladat nem futott rajta. A fõ tesztprogram C nyelven készült, és ODBC hívásokkal tartott kapcsolatot az adatbázis-kezelõ rendszerekkel. Egy második tesztprogram JDBC hívásokkal tesztelte a rendszerek bizonyos hívásokra adott válaszait. Minden tesztet háromszor futtattunk le 10 000 sornyi, véletlenszerûen beszúrt adatra, a lekérdezésben szereplõ oszlopok indexelésével, illetve indexelés nélkül is; az ettõl eltérõ eseteket jelöltük. Az adott DBMS teljesítmény-növekedését a három teszteredmény átlagolásával számítottuk ki. Szeretnénk hangsúlyozni, hogy mutatóink nem jelölnek abszolút értelemben vett teljesítménybeli eredményeket. Az ELÕNY: 4/8 jelzés tehát nem azt jelenti, hogy valamelyik, vagy az összes DBMS teljesítménye 50 százalékkal javult; csupán annyit jelent, hogy a DBMS-ek 50 százalékának javult a teljesítménye, a többi rendszeré pedig nem mutatott változást.

7

8


Hordozhatóság Mivel ennyi különbözõ DBMS-sel dolgozhattunk, a hordozhatósággal kapcsolatban is szolgálhatunk némi információval. A hordozhatóságot roppant fontos kérdésnek tekintjük. Könyvünk elsõsorban ügyfél–kiszolgáló alkalmazásokkal foglalkozik, melyekhez feltehetõen DBMS-tõl független kódot szeretnénk majd írni, sõt, a célrendszer talán teljesen ismeretlen lesz. Hogy függetlenek maradhassunk a gyártók egyéni vonásaitól, ahol lehetséges, az ANSI/ISO SQL:1999 szabványnak megfelelõ SQL nyelvet használtuk az összes példához, illetve az utasításformára vonatkozó magyarázatokhoz. Ahol hiányzik valamely lehetõség a szabványos SQL-bõl, de megvan az összes DBMS-ben – ilyen például a CREATE INDEX utasítás –, ott példáinkban olyan formát használtunk, amit a legtöbb rendszer felismer. Ahol a szabványostól eltérõ vagy kevéssé elterjedt utasításforma fordul elõ, vagy ilyet kellett tesztelni, ott jelöltük ezt. Erre vonatkozóan lásd a „Hordozhatóság” cím alatti megjegyzéseket, amelyekben feltüntettük, hol lehet szükség a szabványostól eltérõ SQL nyelvtanra. További segítségként összehasonlító táblázatokat is készítettünk, melyek kiemelik az SQL szabvány és A Nyolcak közti eltéréseket. Ezekben a táblázatokban olykor egy N/S jelzés látható az ANSI SQL sorban; ez azt jelenti, hogy az SQL szabvány megvalósítás által meghatározottnak tekinti az adott tulajdonságot, azaz a szabvány semmilyen követelményt nem támaszt vele kapcsolatban – a megvalósítás kérdését az adatbázis-kezelõ rendszer készítõjére bízza. Az SQL-változatok együttes optimalizálásának feladata nagyban különbözik egyetlen rendszer behangolásától; könyvünk szigorúan csak az általános kérdésekkel foglalkozik.

Szóhasználat és alapfeltevések Feltételezzük, hogy olvasóink programozók, akik valamilyen SQL DBMS-hez készítenek kódokat, vagy legalábbis erre készülnek. Ennek megfelelõen nem térünk ki az SQL nyelvtanára, illetve a programozási megoldások alapvetõ kérdéseire. Feltételezéseink szerint olvasóink már ismerik az alapvetõ SQL utasításformákat, tudják, hogyan kell egy ODBC-hez vagy JDBC-hez hasonló SQL API-t (Application Programming Interface, alkalmazás-programozási felület) használni, illetve tárolt eljárásokat írni, tisztában vannak az indexek mûködésével, és így tovább. Azt is feltesszük továbbá, hogy olvasóink ismerik az SQL alapfogalmait, melyeket bármely kezdõ szintû SQL-ismertetõ használ. Tegyük fel például, hogy az alábbi módon írunk le egy SELECT utasítást: SELECT WHERE FROM GROUP BY HAVING ORDER BY

1. fejezet • Facilis Descensus Averni A fenti fogalmak feltehetõen már ismerõsek, így nem ismételjük át meghatározásaikat; legfeljebb röviden áttekintjük a leggyakoribb fogalmakat és nyelvi elemeket. Ezenkívül lesznek kevésbé közismert fogalmak is, melyek azonban elengedhetetlenek a könyv megértéséhez. Az ilyen fogalmakat elsõ elõfordulásuk helyén meghatározzuk. Szükség esetén ezek a meghatározások a B függelék szószedetében is megtalálhatók.

Jelölések Példáinkban végig ugyanazt a jelölési módot használjuk. Az SQL kulcsszavakat csupa nagybetûvel jelöljük (például SELECT). A táblák, valamint egyéb fõ SQL-objektumok neveit nagy kezdõbetûvel írjuk (például Table1, Index1); az oszlopok neveit kisbetûvel (például column1). Többsoros utasítások esetén minden sort az adott záradék kulcsszava indít. Szándékosan kerüljük a mindennapi életbõl vett elnevezéseket (például Beosztottak vagy felhaszn_azon), mert az ilyen nevek elvonnák a figyelmet a példák egyetemes jellegérõl. Egyes esetekben azonban, amikor kifejezetten egy adott tulajdonságot kívánunk bemutatni, az elnevezés utal a megnevezett objektum jellegére. Például: SELECT column1, column2 FROM Table1 WHERE indexed_column =

Nem sok SQL szintaxisdiagram fordul elõ a könyvben, de hadd idézzük fel röviden a BNF jelölés (Backus-Naur Form) általunk is használt, jól ismert változatát: • <> A csúcsos zárójel a nyelvi elemek körül látható; a neveket itt valódi adatokkal kell kicserélni. • [] A szögletes zárójelben levõ nyelvi elemeket nem kötelezõ kitennünk; használhatjuk, de el is hagyhatjuk õket. • {} Kapcsos zárójelben a kötelezõ nyelvi elemek csoportjai találhatók; az SQLutasításnak minden csoportból legalább egy elemet tartalmaznia kell. • | A függõleges vonallal elválasztott nyelvi elemek közül az SQL-utasítás legfeljebb csak egyet tartalmazhat.

9

10


Általános megjegyzések „Kerûld a patvart; de, ha benne vagy, Végezd, hogy ellened másszor kerûljön.” – William Shakespeare, Hamlet (Arany János fordítása)

Kezdjük néhány általános jótanáccsal. Az SQL eljárásközpontú (procedurális) nyelv. Bár e kérdésben elég nagy a zûrzavar, és nyilvánvaló hazugságok is elhangzanak, tény, hogy az SQL-utasítások záradékainak feldolgozására meghatározott sorrendben kerül sor, és – az SQL halmazközpontúságától függetlenül – a DBMS-nek az adott mûveletet gyakran soronként kell végrehajtania az eredményhalmazon. Eszerint, ha például az alábbi utasítást adjuk ki: UPDATE Table1 SET column1 = 5 WHERE column2 > 400

az SQL halmazközpontúsága miatt a DBMS elõször meghatározza, hogy hat sor felel meg a frissítéshez szükséges feltételeknek; ezután azonban ténylegesen meg is kell változtatnia ezt a hat sort, méghozzá egyenként. A relációs modell eredendõen hatékony. Dr. Codd szabályai és a normalizálás elvei azon a bizonyított tételen alapulnak, miszerint a matematikai alapok stabil építményt eredményeznek. (A normalizálás az adatbázis oly módon való kialakítását jelenti, hogy annak táblái a relációs elmélet által lefektetett szabályokat kövessék.) A lekérdezéseknél mindig abból induljunk ki, hogy legalább százszor le fogjuk futtatni. Ez arra kényszerít, hogy átgondoljuk, mit is érdemes használnunk (eljárást, nézettáblát, kioldót, vagy esetleg valami egyéb objektumot), és felmerülhet bennünk a következõ kérdés is: „Ha ez tényleg ennyire gyakori, nem lehet, hogy valaki már megírta?” Most pedig vágjunk bele!

Könyvünk témája az ügyfél kiszolgáló alapú SQL rendszerek hangolása. De mit is jelent mindez?

Recommend Documents