Helen Borri - firebird adatbázis fejlesztői útmutató - 107. oldal

TELJES KÜLSŐ CSATLAKOZÁS

Teljes külső kapcsolat (FULL OUTER JOIN) teljes egészében tartalmaz. Az egyes sorokhoz tartozó sorok egy sorát és egy részlegesen töltött sorát adja vissza minden egyes sorhoz, ahol nem találtak egyezést. Ez a kapcsolat ötvözi a jobb és bal kapcsolatok viselkedését.

Ábra. 22.4. Teljes csatlakozás

Itt van egy szolgáltató, amely ugyanazokat a bemeneti áramokat használja, mint az INNER JOIN példa:

A 1. TÁBLÁZATBÓL FOLYÓTANNI 2. táblázat

BE Table1.PK = Table2.FK

Az 1. ábrán. A 22.4 ábra bemutatja, hogy a teljes kapcsolathoz tartozó szálak összevonódnak-e.

Kereszt összeköttetések

A Firebird nem támogatja a cross-connect (CROSS JOIN) nyelvi elemeit, ami egy adatkészletet hoz létre, amely a két táblázatban található Descartes termék. Ez azt jelenti, hogy a baloldali adatfolyam minden sorában a kimeneti stream minden sorból tartalmazni fogja a megfelelő adatfolyamot. Ritkán, ha szüksége van egy Descartes termékre, az SQL-89 szintaxist anélkül használhatja, hogy csatlakozási kritériumokat tartalmazna a WHERE záradékban, például:

SELECT T1. *, T2. * A T1 TABLE1, T2 TABLE2;

A Firebird lekérdezőmotor néha belsőleg létrehozza a keresztkötéseket, amikor a "folyókat" létrehozza a kapcsolati műveletek során (lásd a fejezet "Optimalizálás témaköre" című részét).

Természetes kapcsolatok

Firebird nem támogatja a természetes vegyület (TERMÉSZETES REGISZTRÁCIÓ), más néven equi-join (EQUI REGISZTRÁCIÓ), amely létrehoz egy adatkészlet összekapcsolásával két oszlopban adatfolyamon megfelelő, közönséges azonosítók oszlopok azonos értékeket. A Firebird-ben mindig meg kell adnia a csatlakozási feltételeket.

Kétértelműség a JOIN lekérdezésekben

Az adatbázisok elméletéről szóló különféle könyvekben azt mondják, hogy a kétértelműség csak abban az esetben létezhet, ha egyes oszlopnevek több szálon jelennek meg. Az a személy, aki gyakorlatilag adatbázisokkal dolgozik, egy másik történetet mesélhet. A kétértelműséget kiküszöbölő probléma eltűnik, attól függően, hogy az adatbáziskiszolgáló miként végzi el az elemzést, a szálak létrehozását és az összekapcsolási művelet során végrehajtott rendezést.

Az InterBase engedékeny volt a kapcsolatok egyértelmû szintaxisától való eltérésekhez - néha sikertelen eredményekkel. Ha az alkalmazásod meglévő kódját áthelyezi az InterBase-szal, akkor ne aggódjon az SQL kivételektől, amelyeket a Firebird ad ki a kapcsolatkérések első tesztelésének során. Megmutatja azokat a helyeket a kódban, ahol korábban engedélyezték a lekérdezéseket, amelyek helytelen eredményeket adhatnak vissza.

A Firebird nem fogad el olyan kapcsolati kéréseket, amelyek olyan oszlopokra utalnak, amelyek nem rendelkeznek teljes asztali minõsítõvel. Az asztal minősítő lehet táblázat azonosító vagy táblázat álnév. Az 1.5-ös verziótól kezdve nem keverhetők össze. Ha az 1.0-s verziót használja, legyen állandó, ha nem kívánja újraírni a kódot, amikor új verziókra frissít.

Korábbi példák a táblázatok azonosítóit használták. Az alias táblák használata elegánsabb és kompaktabb, és néhány lekérdezés esetén (lásd a "Reentrant kapcsolatok" részt) kötelező.

Táblázat aliasok

Ha a tábla neve hosszú vagy zavaros, vagy ha sok asztal van, akkor a táblázati álnevek használata hasznos lehet (és bizonyos esetekben szükséges) a szereplők jobb áttekinthetőségéhez. A lekérdező processzor az asztali álnevet szinonímaként kezeli az alias által képviselt táblázat számára. A táblázati álnevek olyan lekérdezések esetén kötelezőek, amelyek ugyanazon a táblázaton több szálat alkotnak.

TIP. Az adatbázis nyelvjárás 3 adatbázist, amely azért jött létre azzal a korlátozott azonosítók (határolt azonosítók), kombinálva egy kis-vagy vegyes nyilvántartások az elnevezés a tárgyak és / vagy a „rossz karakter”, az írás lekérdezések válhat meglehetősen unalmas, gyakran Ha hibákat nem használnak, az aliasokat használják.

Az alias használható bárhol, ahol jogosult az asztal nevére kvalifikálónak nevezni; Az összes táblázat neveit aliasokkal kell helyettesíteni. Az ugyanabban a lekérdezésben szereplő aliasok keverési táblázatazonosítója kivételeket eredményez a Firebird 1.5 és újabb verziókban.

A következő példa a táblázatazonosítót használja:

ÉS C.SALESMAN_ID = '44'

Érvényes táblázat alias nevek

Használja karakterlánc legfeljebb 31 karakter, amely érvényes a metaadat nevét (pl. E. alfanumerikus karakter ASCII tartományban 35-38, 48-57, 64-90 és 97-122). Tilos a helyiségek, az ékezetek, az idézőjelek közé zárt nevek és a számjegyekkel kezdődő nevek.

Belső kurzor

Ábra. 22.5. Belső kurzor két táblázat összekapcsolásához

Reentrant kapcsolatok

A tervezési feltételek néha megkövetelik a két vagy több patak kombinált készletét, amelyek ugyanabból a táblából származnak. Gyakran egy táblázatot hierarchikus, vagy fa-szerű struktúrával vetítenek előre, ahol a táblázat minden egyes sorának logikusan az ugyanabban a táblázatban lévő szülő leszármazottja van. Az asztal elsődleges kulcsa a leszármazási fa csomópontja felé mutat, míg az idegen kulcs oszlopban tárolja a szülő kulcsot, amely az elsődleges kulcs értékére utal a másik sorban.

A szülõ-gyermek kapcsolat "igazítására" irányuló kérelemhez olyan kapcsolatra van szükség, amely a szülõ egyik adatfolyamát lekéri, a másik az ugyanabból a táblából származó leszármazottakra. A szokásos kifejezés erre összekapcsolódik. A reentrant kapcsolat kifejezés morfológiailag jobban megfelel, mert vannak másfajta visszatérő lekérdezések is, amelyek nem használnak kapcsolatokat. Később ebben a fejezetben a Sec. A "Subqueries" a többi típusú visszatérő lekérdezést tárgyalja.

A visszatérő kapcsolatok kurzorai

Reentrant kapcsolat végrehajtásához a kiszolgáló egy belső kurzort tart fenn minden tábla egy táblázatban. Fogalmi szempontból két kurzor kontextusát kezeli, mintha külön táblák lennének. Ebben a helyzetben a táblázat referencia-szintaxisa szükségképpen aliasokat használ a két szál kurzorainak megkülönböztetésére.

A következő példában minden szervezeti egység a szülői azonosítójával kerül tárolásra, amely a menedzsment egységének elsődleges kulcsára mutat. A következő lekérdezés úgy kezeli az egységeket és a szülői egységeket, mintha két táblázat lennének:

D1.DESCRIPTION AS DEPARTMENT,