COMPLETE EXTERIOR COMPLET
O conexiune externă completă (JOIN FULL OUTER) este inclusă în întregime. Se întoarce un rând pentru fiecare pereche de fluxuri corespunzătoare și un rând parțial umplut pentru fiecare rând din fiecare fir, unde nu sa găsit niciun rezultat. Această conexiune combină comportamentul conexiunilor din dreapta și din stânga.
Fig. 22.4. Conexiune completă
Aici este un operator care utilizează aceleași fluxuri de intrare ca și exemplul INNER JOIN:
Din tabelul 1 FULL JOIN Tabelul2
ON Table1.PK = Tabelul2.FK
În Fig. 22.4 arată cum se vor uni firele pentru o conexiune completă.
Conexiuni încrucișate
Firebird nu acceptă elemente de limbă pentru cross-connect (CROSS JOIN), care creează un set de date care este produsul cartezian al a două tabele. Adică, pentru fiecare rând din fluxul din stânga, fluxul de ieșire va conține fiecare linie din fluxul din dreapta. În cazuri rare, când aveți nevoie de un produs cartezian, puteți utiliza sintaxa SQL-89 fără criterii de asociere în clauza WHERE, de exemplu:
SELECTAREA T1. *, T2. * DIN T1 TABELUL 1, T2 TABELUL2;
Motorul de interogare Firebird uneori creează interdependenți atunci când construiește "râuri" în timpul operațiilor de conectare (vedeți secțiunea "Subiecte de optimizare" din acest capitol).
Conexiuni naturale
Firebird nu susține compusul natural (NATURAL TE), de asemenea, cunoscut sub numele de equi-join (EQUI-TE), care creează un set de legătura între două coloane flux de date pe bază de potrivire, folosind coloane comune identificatori cu valori identice. În Firebird, trebuie să specificați întotdeauna condițiile de conectare.
Ambiguitatea în interogările JOIN
În diverse cărți despre teoria bazelor de date, se spune că ambiguitatea poate exista numai atunci când anumite nume de coloane apar în mai multe fire. O persoană care practic lucrează cu bazele de date poate spune o poveste diferită. Problema eliminării ambiguității dispare, în funcție de modul în care serverul de bază de date implementează parsarea, crearea de fire și sortarea care se efectuează în timpul operației de conectare.
Interbase a fost indulgent la abateri de la conexiunile de sintaxă lipsite de ambiguitate - uneori cu rezultate nefericite. Dacă migrați codul existent al aplicațiilor care rulează cu de Interbase, nu fi excepții SQL alarmat de faptul că va da Firebird în primele interogări de testare a alerga cu compușii. Acesta vă va arăta locurile din codul în care au fost acceptate anterior interogări care ar putea să returneze rezultate incorecte.
Firebird nu va accepta solicitările de conectare care conțin referințe la coloane care nu au un calificativ de masă completă. Calificatorul de tabel poate fi un identificator de tabel sau un alias al unui tabel. Începând cu versiunea 1.5, acestea nu ar trebui amestecate. Dacă utilizați versiunea 1.0, fiți consecvent dacă doriți să evitați rescrierea codului când faceți upgrade la versiuni noi.
Exemplele anterioare au folosit identificatorii de tabele. Utilizarea tabelelor de alias este mai elegantă și mai compactă, iar pentru unele interogări (vezi secțiunea "Conexiuni Reentrant") este obligatorie.
Alias-uri de masă
Dacă numele tabelului este lung sau confuz sau dacă există mai multe tabele, utilizarea aliaselor de masă va fi utilă (și, în unele cazuri, necesară) pentru o mai mare claritate a operatorilor. Procesorul de interogare tratează aliasul de tabel ca sinonim pentru tabela reprezentată de alias. Aliasurile de masă sunt obligatorii în interogările care formează mai multe fire din același tabel.
TIP. Dialectul 3 Baza de date de baze de date, care a fost creat cu utilizarea dispozitivelor de identificare limitate (identificatori delimitate), combinate cu un registre mici sau mixte în denumirea obiectelor și / sau folosind „caracterul greșit“, scris interogări poate deveni destul de plictisitoare, de multe ori Dacă nu sunt utilizate erori, se folosesc pseudonime.
Aliasul poate fi folosit ori de câte ori este permis să se refere la numele tabelului ca calificativ; Numele tuturor tabelelor trebuie înlocuite cu aliasuri. Identificarea tabelelor de amestec cu pseudonime în aceeași interogare va duce la excepții în Firebird 1.5 și în versiunile ulterioare.
Următorul exemplu folosește ID-urile tabelului:
ȘI C.SALESMAN_ID = '44'
Nume de alias masă valide
Utilizați orice șir de până la 31 de caractere, care sunt valabile pentru un nume de metadate (de ex., E. caractere alfanumerice în ASCII în intervalul 35-38, 48-57, 64-90 și 97-122). Spațiile, diacriticele, denumirile cuprinse în ghilimele și numele care încep cu o cifră nu sunt permise.
Cursor intern
Fig. 22.5. Cursor intern pentru a conecta două tabele
Reintrant conexiuni
Condițiile de proiectare uneori necesită formarea unui set combinat de două sau mai multe fluxuri care provin din aceeași masă. Deseori, o tabelă este proiectată cu o structură ierarhică sau arborescentă, în care fiecare rând din tabel este logic descendent al părintelui din același tabel. Cheia primară a tabelului indică nodul nod al copacului descendent, în timp ce coloana de chei străine stochează cheia părinte care se referă la valoarea cheii primare din celălalt rând.
Cererea de a "alinia" relația părinte-copil necesită o conexiune care recuperează un flux pentru părinte și celălalt pentru descendenții din același tabel. Termenul obișnuit pentru aceasta este o legătură în sine. Termenul de conectare reentrant este mai adecvat din punct de vedere morfologic, deoarece există și alte tipuri de interogări reentante care nu utilizează conexiuni. Mai târziu, în acest capitol din Sec. "Subqueries" discută despre alte tipuri de interogări reentante.
Cursoare pentru conexiuni reentante
Pentru a efectua o conexiune reentrant, serverul menține un cursor intern pentru fiecare flux din imaginea unui tabel. Conceptual, el tratează contextele a două cursoare, ca și cum ar fi fost tabele separate. În această situație, sintaxa de referință a tabelului utilizează în mod necesar aliasuri pentru a distinge cursorul celor două fire.
În exemplul următor, fiecare unitate organizațională este stocată cu identificatorul părinte, care indică cheia primară a unității sale de gestionare. Următoarea interogare tratează unitățile și unitățile părinte ca și cum ar fi fost două tabele:
D1.DESCRIPTION AS DEPARTAMENT,
Trimiteți-le prietenilor: