„SQL” változatai közötti eltérés

[ellenőrzött változat][ellenőrzött változat]
Tartalom törölve Tartalom hozzáadva
a Informatikai portál AWB
Nincs szerkesztési összefoglaló
1. sor:
Az '''SQL''', azaz '''Structured Query Language''' (strukturált lekérdezőnyelv) [[relációs adatbázis-kezelő]]k lekérdezési nyelve.
 
Angol nyelvterületen 'eszkjuel' a kiejtése. A hagyományokhoz való hűség jegyében sokan 'szíkvel'-nek ejtik, ugyanis korábban '''Structured English Query Language''' (SEQUEL) volt az elnevezés, és ezt rövidítették le.
'szíkvel'-nek ejtik, ugyanis korábban '''Structured English Query Language''' (SEQUEL) volt az
elnevezés, és ezt rövidítették le.
 
A [[Relációsadatbázis-kezelő rendszer|relációsadatbázis-kezelő]]k általában az SQL nyelven programozhatók. Az SQL alapvető utasításait közel egyformán valósítják meg, de a később beépült nyelvi elemek körében nagyon nagy az eltérés, az [[kompatibilitás (technika)|inkompatibilitás]], emiatt számos SQL nyelvjárásról beszélhetünk.
nagy az eltérés, az [[kompatibilitás (technika)|inkompatibilitás]], emiatt számos SQL nyelvjárásról beszélhetünk.
 
Jellegét tekintve ez a [[szakterület-specifikus nyelv]] részben procedurális, részben deklaratív.
12 ⟶ 9 sor:
== Az SQL története ==
 
Az SQL alapjait az [[IBM]]-nél fektették le, még az 1970-es években. Elvi alapot a [[relációs adatmodell]] szolgáltatott, amit [[Edgar F. Codd]] híres 12 szabályával írt le először, [[1970]]-ben.
[[relációs adatmodell]] szolgáltatott, amit [[Edgar F. Codd]] híres 12 szabályával
írt le először, [[1970]]-ben.
 
Az [[IBM]], az [[Oracle]] és más gyártók is érdekeltek voltak egy szabványos lekérdező nyelv kifejlesztésében, amivel a [[relációs adatbázis]]ok programozhatók. Az iparági összefogással létrejött ANSI NCITS (National Committee on Information Technology Standards) H2 csoport lerakta az SQL alapjait.
lekérdező nyelv kifejlesztésében, amivel a [[relációs adatbázis]]ok programozhatók.
Az iparági összefogással létrejött ANSI NCITS (National Committee on Information Technology Standards) H2 csoport
lerakta az SQL alapjait.
 
A szabványt az [[ANSI]] (Amerikai Nemzeti Szabványügyi Intézet – American National Standards Institute) [[1986]]-ban, az [[Nemzetközi Szabványügyi Szervezet|ISO]] (Nemzetközi Szabványügyi Szervezet – International Organization for Standardization) [[1987]]-ben jegyezte be. Az első változatot SQL86 néven is szokták emlegetni.
[[1986]]-ban, az [[Nemzetközi Szabványügyi Szervezet|ISO]] (Nemzetközi Szabványügyi Szervezet – International Organization for Standardization)
[[1987]]-ben jegyezte be. Az első változatot SQL86 néven is szokták emlegetni.
 
Az SQL-t folyamatosan továbbfejlesztették, és hat jelentős kiadást különböztetünk meg:
29 ⟶ 19 sor:
* SQL89
* SQL92
* SQL99 (v. más néven: SQL3)
* SQL:2006
* SQL:2008
 
Az első kivételével mindegyik szabvány többszintű megvalósítást tesz lehetővé a gyártóknak (belépő szintű, közepes vagy teljes). Általában a későbbi szabványok belépő szintjei az előző szabvány teljes szintjeinek felelnek meg.
gyártóknak (belépő szintű, közepes vagy teljes).
Általában a későbbi szabványok belépő szintjei az előző szabvány teljes szintjeinek
felelnek meg.
 
== Az SQL nyelv ==
 
Az SQL nyelvi elemeket 4 részre, adatdefiníciós (Data Definition Language, DDL), adatkezelési (Data Manipulation Language, DML), lekérdező (QUERY( Language - QL)) és adatvezérlő (Data Control Language, DCL) részekre lehet bontani.
adatkezelési (Data Manipulation Language, DML), lekérdező (QUERY( Language - QL)) és adatvezérlő (Data Control Language, DCL) részekre lehet bontani.
 
A nyelvben az utasításokat a '''pontosvessző''' választja el egymástól.
88 ⟶ 74 sor:
Az SQL talán leggyakrabban használt utasítása a '''lekérdezés'''. Ez a nyelvi elem inkább deklaratívnak<ref>http://www.cs.bme.hu/dok/szeredi.html</ref> tekinthető, mint procedurálisnak, hiszen a felhasználó (programozó) csak az eredményhalmaz mezőit (oszlopait) és a halmaz felépítésének feltételeit határozza meg, a leválogatási algoritmus elkészítése az [[adatbázis-kezelő]] feladata.
 
A SELECT utasítás az adatok egy halmazát válogatja ki egy táblázatba a [[relációs adatbázis]]ból, és teszi elérhetővé valamilyen technikával a felhasználó számára. Mivel elég nagy adatmennyiségekről lehet szó (szélsőséges esetben az egész adatbázisról), ezért a halmaz általában szekvenciálisan olvasható. Egy mutató (kurzor) mozgatható az eredmény halmazon előre vagy hátra, és kiolvasható, hogy milyen adatok vannak a mutató alatt. Ha a mutató az eredményhalmaz végére vagy elejére ért, azt különleges jelzéssel tudatja az adatbázis-kezelő (EOF – End of File – állomány vége, illetve BOF – Beginning of File, állomány eleje)
A SELECT utasítás az adatok egy halmazát válogatja ki egy táblázatba a [[relációs adatbázis]]ból,
és teszi elérhetővé valamilyen technikával a felhasználó számára.
Mivel elég nagy adatmennyiségekről lehet szó (szélsőséges esetben az egész
adatbázisról), ezért a halmaz általában szekvenciálisan olvasható. Egy mutató
(kurzor) mozgatható az eredmény halmazon előre vagy hátra, és kiolvasható,
hogy milyen adatok vannak a mutató alatt. Ha a mutató az eredményhalmaz
végére vagy elejére ért, azt különleges jelzéssel tudatja az adatbázis-kezelő
(EOF – End of File – állomány vége, illetve BOF – Beginning of File, állomány eleje)
 
Példa:
106 ⟶ 85 sor:
ORDER BY Tulajdonos
</source>
A fenti példa kilistázza azokat a személyeket, akiknek egynél több aktív bankszámlája van. Az első oszlopban az aktív bankszámlák száma, a másodikban a tulajdonosok neve olvasható. A táblázat a tulajdonosok neve szerinti emelkedő sorrendben jelenik meg.
van. Az első oszlopban az aktív bankszámlák száma, a másodikban a tulajdonosok neve
olvasható. A táblázat a tulajdonosok neve szerinti emelkedő sorrendben jelenik meg.
 
A SELECT utasítás több szakaszból állhat, amelyek közül majdnem mindegyik elhagyható, ha szükséges. Az egyes szakaszok magyarázata:
ha szükséges. Az egyes szakaszok magyarázata:
===== SELECT =====
Az eredményhalmaz oszlopait kell itt felsorolni. Nagyon hasznos, hogy további SELECT-ek is lehetnek benne!
SELECT-ek is lehetnek benne!
 
Példa:
157 ⟶ 132 sor:
LEFT esetén: az első tábla adatai akkor is szerepelnek, ha nincs illeszkedő adat a másodikban (azaz a fenti példában megmutatja azokat a betegeket is, akinek soha nem volt kezelése)
 
RIGHT esetén: aza második tábla adatai akkor is szerepelnek, ha nincs illeszkedő adat az elsőben (itt ugyanazt az eredményt adja, mint INNER esetén, ha minden kezeléshez tartozik beteg)
 
FULL OUTER: mindkét táblából megmutatja az összes sort (itt megegyezik a LEFT JOIN eredményével, ha minden kezeléshez tartozik beteg
182 ⟶ 157 sor:
GROUP BY Tulajdonos
</source>
A fenti példa a ''Tulajdonos'' oszlop alapján csoportosítja a sorokat. A SELECT részben lévő COUNT(*) egy-egy csoport sorainak számát adja vissza, az összevonás előtt.
lévő COUNT(*) egy-egy csoport sorainak számát adja vissza, az összevonás előtt.
 
===== HAVING =====
A WHERE-hez hasonlóan itt is szűrést fogalmazhatunk meg, azonban itt a csoportosítás utáni eredményhalmazra. Példa:
utáni eredményhalmazra. Példa:
<source lang="sql">
SELECT COUNT(*), Tulajdonos
195 ⟶ 168 sor:
HAVING COUNT(*) > 1
</source>
Az előző példához képest itt annyi a módosulás, hogy csak azok a csoportok jelennek meg, amelyek egynél több sorból lettek összevonva.
meg, amelyek egynél több sorból lettek összevonva.
 
===== ORDER BY =====
256 ⟶ 228 sor:
Angolul query plan.
 
A kurzor létrehozásának technikája adja az SQL kiszolgálók igazi erejét. Nem mindegy ugyanis, hogy sikerül-e a táblákat megfelelő oszlopok (és indexek!) segítségével összekapcsolni, és ezekből kurzort készíteni, vagy pedig átmeneti táblát kell létrehozni az eredményeknek.
ugyanis, hogy sikerül-e a táblákat megfelelő oszlopok (és indexek!) segítségével összekapcsolni,
és ezekből kurzort készíteni, vagy pedig átmeneti táblát kell létrehozni az eredményeknek.
 
Az egyes relációsadatbázis-kezelők egymástól igen eltérő algoritmusokat használnak a lekérdezési tervek megalkotásához. Gyakori a ''szabályalapú'' (rule-based), és a ''költségalapú'' (cost-based) lekérdezésiterv-készítés. A költségalapú lekérdezési tervhez ismerni kell az adatok [[statisztika]]i eloszlását: átlagát, szórását stb. A szabályalapú lekérdezéseknél elegendő csak a [[relációs adatbázis]] szerkezetének ismerete. A legtöbb relációsadatbázis-kezelő a kettő valamilyen kombinációjával dolgozik.
Az egyes relációsadatbázis-kezelők egymástól igen eltérő algoritmusokat használnak
a lekérdezési tervek megalkotásához. Gyakori a ''szabályalapú'' (rule-based), és a ''költségalapú'' (cost-based)
lekérdezésiterv-készítés. A költségalapú lekérdezési tervhez ismerni kell az adatok
[[statisztika]]i eloszlását: átlagát, szórását stb. A szabályalapú lekérdezéseknél
elegendő csak a [[relációs adatbázis]] szerkezetének ismerete. A legtöbb relációsadatbázis-kezelő
a kettő valamilyen kombinációjával dolgozik.
 
Sok gyártó SQL megvalósításában lehetséges a keresési stratégia befolyásolása, úgynevezett programozói ''lekérdezési tippek'' (query hints) segítségével. Azonban minél jobb egy adatbázis-kezelő, annál kevésbé szükséges ezek használata.
programozói ''lekérdezési tippek'' (query hints) segítségével. Azonban minél jobb egy
adatbázis-kezelő, annál kevésbé szükséges ezek használata.
 
==== INSERT ====
299 ⟶ 262 sor:
=== Egyéb utasítások ===
 
Az SQL-t az idők során kiegészítették olyan tulajdonságokkal, hogy a programozók képesek legyenek benne bonyolult algoritmusokat is írni. Ez akkor válhat szükségessé, ha például komoly adatkezelési feladatokat szeretnénk az ügyféloldalról a kiszolgálóoldalra áthelyezni, az ott elérhető sokkal nagyobb teljesítmény miatt. De az is lehet, hogy csak egyszerűsíteni akarjuk a programozást felhasználói függvények létrehozásával (például szükségünk lenne egy olyan függvényre, ami a TAJ számból kiszedi a szóközöket).
Az SQL-t az idők során kiegészítették olyan tulajdonságokkal, hogy a programozók
képesek legyenek benne bonyolult algoritmusokat is írni.
Ez akkor válhat szükségessé, ha például komoly adatkezelési feladatokat
szeretnénk az ügyféloldalról a kiszolgálóoldalra áthelyezni, az ott
elérhető sokkal nagyobb teljesítmény miatt. De az is lehet, hogy csak
egyszerűsíteni akarjuk a programozást felhasználói függvények létrehozásával
(például szükségünk lenne egy olyan függvényre, ami a TAJ számból
kiszedi a szóközöket).
 
Az SQL nyelv részei a változókezelés, elágazások, ciklusok kezelése, kivételkezelés stb.
 
A legnagyobb különbségek az SQL kiszolgálók között éppen ezeknél a nyelvi elemeknél adódik: ahány gyártó, annyiféle megvalósítás.
adódik: ahány gyártó, annyiféle megvalósítás.
 
Az egyéb nyelvi elemek szemléltetésére álljon itt egy Sybase ASA SQL példa:
350 ⟶ 305 sor:
=== Összekapcsolás ===
 
Az SQL kiszolgálók egy része támogatja a SELECT-FROM szakaszba írt összekapcsolási utasításokat, mások csak a SELECT-WHERE szakaszban fogadják el:
mások csak a SELECT-WHERE szakaszban fogadják el:
 
Összekapcsolás a SELECT-FROM-ban:
367 ⟶ 321 sor:
=== Keresés ===
 
Bizonyos SQL kiszolgálók gyors keresésnél csak a teljesen pontosan beírt keresőkérdésre találják meg a választ. Gondot kell fordítanunk a kis- és nagybetűkre, valamint az ékezetek helyes használatára ([[Oracle]], [[Firebird]], [[PostgreSQL]]).
meg a választ. Gondot kell fordítanunk a kis- és nagybetűkre, valamint az ékezetek
helyes használatára ([[Oracle]], [[Firebird]], [[PostgreSQL]]).
 
Más SQL kiszolgálók képesek figyelmen kívül hagyni az ékezeteket és egyenrangúnak tekintik a kis- és nagybetűket a keresés során, ha ezt kérjük ([[Sybase ASE]], [[Sybase ASA]]).
a kis- és nagybetűket a keresés során, ha ezt kérjük ([[Sybase ASE]], [[Sybase ASA]])..
 
=== FROM nélküli SELECT ===
380 ⟶ 331 sor:
SELECT SYSDATE
</source>
A fenti példa egyes SQL kiszolgálók esetében nem működik, mivel a FROM náluk kötelező nyelvi elem.
nyelvi elem.
 
Ezért például az [[Oracle]] minden adatbázisában szerepelteti a ''DUAL'' táblát, amelynek egyetlen rekordja van. Így [[Oracle]] SQL-ben ezt kell írnunk:
rekordja van. Így [[Oracle]] SQL-ben ezt kell írnunk:
<source lang="sql">
SELECT SYSDATE FROM DUAL
A lap eredeti címe: „https://hu.wikipedia.org/wiki/SQL