Dlaczego SQL jest znany jako język funkcjonalny / oparty na relacjach?

Uczymy się, że większość języków jest klasyfikowana jako jedna z dwóch, „oparta na relacjach” lub „na wysokim poziomie”. Nigdy wcześniej nie korzystałem z SQL, ale po odczytaniu jego składni wydaje się bardziej składnią imperatywną / wysokiego poziomu niż funkcjonalną / opartą na relacjach (Lisp, Haskell)?

Lub może być tak, że moja interpretacja notatek wykładowych mojego profesora jest błędna ... ale zdecydowanie wymienia SQL jako jeden z języków opartych na relacjach (w przeciwieństwie do wysokiego poziomu) i równoważy oparty na relacjach z funkcjonalnym ... a może dlatego, że nie rozumiem, dlaczego fakt, że SQL zajmuje się relacyjnymi bazami danych, czyni funkcjonalnym językiem sposób, w jaki powinien zostać zaimplementowany? (i dlaczego „oparty na relacjach” równa się z „funkcjonalnym” podczas kategoryzacji języków programowania?)

Dzięki :)

Uczymy się, że większość języków jest klasyfikowana jako jedna z dwóch, „oparta na relacjach” lub „na wysokim poziomie”.

Te pojęcia są ortogonalne. „Oparte na relacjach” oznacza, że ​​semantyka języka opiera się na pojęciu relacji, to znaczy powiązaniu typu „wiele do wielu” między dwoma zestawami (relacje są matematyczną podstawą tabel SQL). „Wysoki poziom” oznacza, że ​​język zawiera wiele abstrakcji, które ukrywają wiele podstawowych szczegółów technicznych (takich jak lokalizacje pamięci, rejestry procesora, dostęp do dysku, operacje bitowe itp.). SQL jest z pewnością oparty na relacjach, ponieważ jego głównym celem jest opisanie relacyjnych danych i operacji na nim. SQL jest również dość wysokim poziomem; nie zapewnia żadnego bezpośredniego dostępu do bajtów na dysku i nie podaje żadnych szczegółów na temat tego, jak przechowuje swoje dane (przynajmniej standardowy SQL nie;

W rzeczywistości istnieje wiele innych osi, wzdłuż których można klasyfikować języki programowania (i danych); szczególnie interesujący jest deklaratywny vs. imperatywny . Języki deklaratywne opisują, co to jest ; imperatywne języki opisują, jak coś zrobić . DDL częścią SQL jest głównie deklaratywny, pomimo słów kluczowych niezmiernie wyglądzie (” CREATE TABLE”, « DROP DATABASE», itd.), A nawet część manipulacji danymi ( SELECT, UPDATE, INSERT, DELETE) jest nadal dość deklaratywny. Bardzo interesującą właściwością SQL jest to, że nie jest on ukończony przez Turinga: nie można pisać nieograniczonej pętli w zwykłym standardowym SQL ANSI.

Funkcjonalne programowanie koncentruje się wokół kilku podstawowych pomysłów:

• funkcje są pierwszorzędnymi obywatelami (tzn. mogą być używane jako wartości, dane wejściowe do innych funkcji i dane wyjściowe z innych funkcji)
• funkcje wyższego rzędu (funkcje działające na funkcjach lub funkcje zwracające funkcje)
• czystość (czysta funkcja to taka, która nie ma skutków ubocznych; czysta funkcja nie może wykonywać żadnych operacji we / wy, nie może czytać ani modyfikować żadnego stanu globalnego, ani nie może przyjmować argumentów niestanowiących odniesienia. Czyste funkcje są szczególnie interesujące, ponieważ będą zawsze produkują tę samą moc wyjściową przy tych samych danych wejściowych)

SQL z pewnością nie obraca się wokół funkcji jako głównego narzędzia do modelowania rzeczy, ale w pewnym sensie obejmuje ideę czystości - to samo zapytanie uruchomione w tej samej bazie danych przyniesie ten sam wynik za każdym razem (z wyjątkiem zamawiania). Nazywanie SQL „językiem funkcjonalnym” jest trochę skomplikowane przez IMO.

SQL nie jest konieczny, ponieważ proces rozwiązywania zapytań i relacji HOW nie jest definiowany przez programistę, lecz przez kompilator / optymalizator / interpreter. SQL jest językiem deklaratywnym - w SQL deklarujesz relacje. Tworzy to strukturę danych (która nie jest fizycznie zdefiniowana w języku, ale przez jej implementację) przy użyciu wstawek, aktualizacji i usunięć.

Wykorzystanie relacji odbywa się następnie za pomocą zapytań (instrukcji SELECT), które działają tak, że nie mają skutków ubocznych.

Całość jest owinięta wokół modelu relacyjnego .

SQL nie jest tak bardzo funkcjonalnym językiem, jak deklaratywnym. Języki funkcjonalne, ogólnie rzecz biorąc, kładą nacisk na styl deklaratywny na imperatywny, aby zminimalizować skutki uboczne. Może to spowodować, że niektórzy określą SQL jako funkcjonalny, ale nie jest on dokładny. Jest deklaratywny z elementami proceduralnymi.

Czy to możliwe, że twoje notatki są zakodowane?

Nigdy nie słyszałem, aby języki programowania były podzielone na „oparte na relacjach” i „na wysokim poziomie”. Poziom niski / wysoki jest zwykle używany do odróżnienia asemblera i C od języków, które zapewniają bezpośrednie wsparcie dla bardziej abstrakcyjnych struktur. Relacje są dość abstrakcyjną strukturą, więc powiedziałbym, że wszystko, co wspiera relacje, jest z definicji na wysokim poziomie.

Czysty SQL jest zwykle opisywany jako język deklaratywny, z różnymi bitami proceduralnymi rozwiązywanymi przez różnych dostawców. Fakt, że SQL nie obsługuje funkcji jako zmiennych, wydaje mi się natychmiast dyskwalifikować go jako język funkcjonalny.

SQL jest relacyjnym językiem opartym na zestawach, na którym wprowadzono funkcje proceduralne.

Nie wiem, czy bym rozważył funkcjonalność SQL, jednak ma ona pewne aspekty języków funkcjonalnych. Nowoczesne warianty SQL (z bitami proceduralnymi) zdecydowanie nie działają.

Myślę, że SQL to cukier składniowy wokół algebry relacyjnej + coś więcej. Algebra relacyjna ma dużą moc języków funkcjonalnych, w rzeczywistości wykorzystuje funkcje bardzo dużej mocy wyrażania (selekcja, rzutowanie, zmiana nazwy, łączenie, łączenie, przecinanie ...). Ale o ile wiem, podstawowe leczenie algebry relacyjnej zwykle nie ma odpowiednika operatora lambda, chociaż można je bezproblemowo rozszerzyć za pomocą operatora rekurencyjnego.

Myślę, że algebra relacji jest raczej językiem algebraicznym. SQL wraz ze swoimi podkwerendami przeszedł z czystej algebry relacyjnej do bardziej funkcjonalnego stylu, ale bez operatora lambda myślę, że nie jest to język w pełni funkcjonalny. Nie wiem, czy można go bezproblemowo rozszerzyć na w pełni funkcjonalny język, nie jestem ekspertem w tej dziedzinie. Haskell ma kilka bibliotek przeznaczonych do języków baz danych bardzo wysokiego poziomu.

Nie znam wszystkich subtelności tego, czego potrzebuje, aby język został zakwalifikowany jako funkcjonalny, ale Sql Server wprowadził bardzo interesujący sposób pracy z funkcjami. Specjalna klauzula umożliwia funkcjom współdziałanie w zapytaniu. Nazywa się to Apply. Kiedy wyjaśniłem to byłemu programistowi APL, powiedział mi, że w APL istnieje podobna klauzula dla podobnego celu. Klauzula Apply pozwala przekazać zestaw atrybutów z wiersza tabeli lub wiersza funkcji tabeli jako dane wejściowe do innej funkcji. To powiedziawszy, nałożyłem ograniczenie na rodzaj funkcji tabeli, aby pisać, aby można ją było uznać za funkcjonalną. Musi być zadeklarowany jako wbudowany, co oznacza, że ​​jest wyrażony jako pojedyncza instrukcja select. To narzuca brak zmiennych. Takie zapytania o dużej logice można napisać, pod warunkiem że używasz wspólnych wyrażeń tabelowych, które następnie pozwalają na przekształcenie wyrażeń w kolumnę, rodzaj niezmiennej zmiennej, która może być ponownie użyta w innych CTE. W końcu funkcja .. staje się bardzo dużym makrem, dzięki czemu optymalizator może optymalizować sposób, w jaki potrzebuje. Jedyne, czego brakuje ludziom, to kilka prostych sztuczek, aby napisać logikę warunkową i zadeklarować logikę danych w zapytaniu. Na koniec niektóre funkcje wykorzystujące klauzulę over są potrzebne jako sposób, w jaki ro realizuje wyniki jako wartość użyteczną w rzędzie z innych wierszy, ale tutaj byłoby trochę za długo. Jedyne, czego brakuje ludziom, to kilka prostych sztuczek, aby napisać logikę warunkową i zadeklarować pewne dane obsługujące logikę w zapytaniu. Na koniec niektóre funkcje wykorzystujące klauzulę over są potrzebne jako sposób, w jaki ro realizuje wyniki jako wartość użyteczną w rzędzie z innych wierszy, ale tutaj byłoby trochę za długo. Jedyne, czego brakuje ludziom, to kilka prostych sztuczek, aby napisać logikę warunkową i zadeklarować pewne dane obsługujące logikę w zapytaniu. Na koniec niektóre funkcje wykorzystujące klauzulę over są potrzebne jako sposób, w jaki ro realizuje wyniki jako wartość użyteczną w rzędzie z innych wierszy, ale tutaj byłoby trochę za długo.