Języki zapytań QUEL
Rodzina | Język zapytań |
---|---|
Zaprojektowany przez | Michaela Stonebrakera |
Po raz pierwszy pojawiły się | 1976 |
Główne wdrożenia | |
Ingres , POSTQUEL | |
Pod wpływem | |
Alpha |
QUEL jest językiem zapytań do relacyjnych baz danych , opartym na rachunku relacyjnym krotek , z pewnymi podobieństwami do języka SQL . Został stworzony jako część Ingres DBMS na Uniwersytecie Kalifornijskim w Berkeley , w oparciu o wcześniej sugerowany przez Codda , ale nie zaimplementowany język Data Sub-Language ALPHA . QUEL był używany przez krótki czas w większości produktów opartych na ogólnodostępnym kodzie źródłowym Ingres, zwłaszcza w implementacji o nazwie POSTQUEL obsługiwanej przez POSTGRES . Gdy Oracle i DB2 zyskały udział w rynku na początku lat 80., większość firm obsługujących wówczas QUEL przeniosła się zamiast tego na SQL. [ potrzebne źródło ] QUEL jest nadal dostępny jako część Ingres DBMS, chociaż przez wiele lat nie dodano żadnych ulepszeń językowych specyficznych dla QUEL. [ kiedy? ]
Stosowanie
Instrukcje QUEL są zawsze definiowane przez zmienne krotki , których można używać do ograniczania zapytań lub zwracania zestawów wyników. Rozważmy przykład zaczerpnięty z jednego z pierwszych oryginalnych artykułów Ingres:
zakres E to PRACOWNIK , który jest pobierany do W ( COM = E. Wynagrodzenie / ( E. Wiek - 18 )) , gdzie E. Imię = „Jones”
Tutaj E jest zmienną krotki, która rozciąga się na relację PRACOWNIK i znaleziono wszystkie krotki w tej relacji, które spełniają kwalifikację `E.Name = "Jones"`. Wynikiem zapytania jest nowa relacja W, która ma pojedynczą domenę COMP obliczoną dla każdej krotki kwalifikacyjnej. Można wówczas zadać dodatkowe pytania względem relacji W.
Równoważna instrukcja SQL to:
utwórz tabelę W jako wybierz ( E . wynagrodzenie / ( E . wiek - 18 )) jako COMP od pracownika jako E gdzie E . imię = „Jones”
W tym przykładzie relacja jest przechowywana w nowej tabeli W. Nie jest to bezpośredni odpowiednik wersji QUEL; relacje w QUEL są bardziej podobne do tabel tymczasowych spotykanych w większości współczesnych implementacji SQL.
Oto przykład prostej sesji, która tworzy tabelę, wstawia do niej wiersz, a następnie pobiera i modyfikuje zawarte w niej dane, a na koniec usuwa dodany wiersz (zakładając, że nazwa jest unikalnym polem).
QUEL | SQL-a |
---|---|
utwórz ucznia ( imię = c10 , wiek = i4 , płeć = c1 , stan = c2 ) zakres s to uczeń dołącz do s ( imię = „philip” , wiek = 17 , płeć = „ m” , stan = „FL” ) odzyskać
( s . wszyscy ) gdzie s . stan = "FL" zamień s ( wiek = s . wiek + 1 ) odzyskaj ( s . wszystko ) usuń s gdzie s . imię = „Filip”
|
utwórz tabelę student ( znak imienia ( 10 ), int wieku , znak płci ( 1 ), znak stanu ( 2 )); wstaw do ucznia ( imię , wiek , płeć , stan ) wartości ( 'philip' , 17 , 'm' , 'FL' );
wybierz * od ucznia , gdzie stan = 'FL' ; zaktualizuj zestaw uczniów wiek = wiek + 1 ; wybierz * od ucznia ; usuń ucznia , gdzie imię = 'philip' ;
|
Kolejną cechą QUEL był wbudowany system masowego przenoszenia rekordów do i z systemu. Rozważ to polecenie:
skopiuj ucznia ( imię=c0, przecinek=d1, wiek=c0, przecinek=d1, płeć=c0, przecinek=d1, adres=c0, nl=d1 ) do „ /student.txt”
który tworzy plik rozdzielany przecinkami zawierający wszystkie rekordy w tabeli uczniów. d1 wskazuje ogranicznik, a nie typ danych. Zamiana na
na z
odwraca proces. Podobne polecenia są dostępne w wielu systemach SQL, ale zwykle jako narzędzia zewnętrzne, a nie wewnętrzne w języku SQL. To sprawia, że są one niedostępne dla procedur przechowywanych.
QUEL ma niezwykle potężne możliwości agregacji. Agregaty mogą być zagnieżdżane, a różne agregaty mogą mieć niezależne listy pomocnicze i/lub klauzule ograniczające. Na przykład:
odzyskać ( a = liczba ( y . i przez y . d gdzie y . str = "ii*" lub y . str = "foo" ), b = max ( liczba ( y . i przez y . d )))
Ten przykład ilustruje jedno z prawdopodobnie mniej pożądanych dziwactw QUEL, a mianowicie to, że wszystkie porównania ciągów są potencjalnie dopasowaniami do wzorców. y.str = "ii*"
dopasowuje wszystkie wartości y.str zaczynające się od
ii
. W przeciwieństwie do tego, SQL używa =
tylko do dokładnych dopasowań, podczas gdy like
jest używane, gdy wymagane jest dopasowanie wzorca.
Zobacz też
- D4 (język programowania) (implementacja D)
- Algebra relacyjna
- Rachunek relacyjny
Dalsza lektura
- CJ Date: Krytyka języka baz danych SQL . SIGMOD Rekord 14(3): 8-54, 1984.