우리는 대부분의 언어가 "관계 기반"또는 "높은 수준"의 두 가지로 분류된다는 것을 알고 있습니다. 이전에 SQL을 사용한 적이 없지만 구문을 읽는 것보다 기능 / 관계 기반 (Lisp, Haskell)보다 명령 / 고수준 구문처럼 보입니다.
또는 교수의 강의 노트에 대한 나의 해석이 잘못되었을 수도 있습니다 ...하지만 SQL을 관계형 언어 중 하나 (고급이 아닌)로 나열하고 기능과의 관계 기반과 동일합니다 ... 또는 SQL이 관계형 데이터베이스를 처리한다는 사실이 기능 언어를 구현 방식으로 만드는 이유를 이해하지 못하는 것일까 요? (그리고 프로그래밍 언어를 분류 할 때 '관계 기반'이 '기능'과 동일한 이유는 무엇입니까?)
감사 :)
답변:
우리는 대부분의 언어가 "관계 기반"또는 "높은 수준"의 두 가지로 분류된다는 것을 알고 있습니다.
이러한 개념은 직교합니다. "관계 기반"은 언어의 의미가 관계의 개념, 즉 두 세트 사이의 다 대다 연관 (상대 관계는 SQL 테이블의 수학적 기초)을 기반으로 함을 의미합니다. "고수준"은 언어에 기본 기술 세부 사항 (메모리 위치, CPU 레지스터, 디스크 액세스, 비트 연산 등)을 숨기는 많은 추상화가 포함되어 있음을 의미합니다. SQL의 주요 목적은 관계형 데이터와 그에 대한 작업을 설명하는 것이므로 SQL은 확실히 관계에 기반합니다. SQL도 상당히 높은 수준입니다. 디스크의 바이트에 직접 액세스하는 수단을 제공하지 않으며 데이터를 저장하는 방법에 대한 세부 정보를 제공하지 않습니다 (적어도 표준 SQL은 그렇지 않습니다.
실제로 프로그래밍 언어와 데이터를 분류 할 수있는 축이 더 많습니다. 특히 흥미로운 것은 선언적 대 명령 적 입니다. 선언적 언어는 뭔가가 무엇인지 설명 이다 ; 명령형 언어 는 무언가 를 수행 하는 방법을 설명합니다 . SQL의 DDL 부분은 ( "명령형 보이는 키워드에도 불구하고, 대부분의 선언이다 CREATE TABLE", " DROP DATABASE", 등), 심지어 데이터 조작 부분은 ( SELECT, UPDATE, INSERT, DELETE)는 여전히 꽤 선언이다. SQL의 매우 흥미로운 속성은 Turing complete가 아니라는 것입니다. 일반 표준 ANSI SQL에서 무한 루프를 작성할 수 없습니다.
기능적 프로그래밍은 몇 가지 핵심 아이디어를 중심으로합니다.
SQL은 확실히 기능을 모델링하는 주요 도구 인 함수를 중심으로하지는 않지만 순도 아이디어를 어느 정도 수용합니다. 동일한 데이터베이스에서 동일한 쿼리를 실행하면 매번 동일한 결과가 생성됩니다 (주문 제외). SQL을 '기능적'언어라고 부르는 것은 IMO를 통해 약간의 확장입니다.
쿼리 및 관계가 해결되는 프로세스는 프로그래머가 아니라 컴파일러 / 최적화 기 / 인터프리터가 정의하므로 SQL은 필수적이지 않습니다. SQL은 선언적 언어입니다 . SQL에서는 관계를 선언합니다. 이렇게하면 삽입, 업데이트 및 삭제를 사용하여 데이터 구조 (언어로 물리적으로 정의되지 않고 구현에 의해 다시 정의 됨)가 구축됩니다.
그런 다음 관계 사용은 부작용이 없다는 점에서 기능하는 쿼리 (SELECT 문)를 사용하여 수행됩니다.
모든 것은 관계형 모델을 둘러싼 다 .
노트가 뒤섞 일 수 있습니까?
프로그래밍 관계가 "관계 기반"과 "높은 수준"으로 구분되는 것을 들어 본 적이 없습니다. 낮은 수준 / 높은 수준은 일반적으로 더 추상적 인 구조를 직접 지원하는 언어와 어셈블러 및 C를 구별하는 데 사용됩니다. 관계는 매우 추상적 인 구조이므로 관계를 지원하는 모든 것이 정의에 의해 높은 수준이라고 말하고 싶습니다.
순수 SQL은 일반적으로 선언적 언어로 설명되며 다양한 공급 업체에서 일부 절차 적 비트를 사용합니다. SQL이 변수로 함수를 지원하지 않는다는 사실은 함수형 언어에서 즉시 자격을 잃는 것으로 보입니다.
내 생각에 SQL은 관계 대수 + 그 이상의 무언가에 대한 구문 설탕이라고 생각합니다. 관계형 대수에는 기능 언어가 많은 힘이 있으며 실제로 표현력이 매우 높은 기능 (선택, 프로젝션, 이름 바꾸기, 조인, 조합, 교차점)을 활용합니다. 그러나 내가 아는 한 관계형 대수의 기본 처리에는 일반적으로 람다 연산자와 동등한 것이 없지만 재귀 연산자로 완벽하게 확장 될 수는 있습니다.
관계 대수는 오히려 대수 언어라고 생각합니다. 하위 쿼리가있는 SQL은 순수한 관계형 대수에서보다 기능적인 스타일로 이동했지만 람다 연산자가 없으면 전체 기능 언어가 아니라고 생각합니다. 나는 그것이 완벽한 방식으로 완전한 기능의 언어로 확장 될 수 있는지 모르겠다. 나는이 분야의 전문가가 아니다. Haskell은 매우 높은 수준의 데이터베이스 언어를 목표로하는 일부 라이브러리를 보유하고 있습니다.
언어가 기능적으로 자격을 갖추는 데 필요한 모든 미묘한 부분을 알지 못하지만 Sql Server는 기능을 다루는 매우 interresting 방법을 도입했습니다. 특수 절은 함수가 쿼리에서 서로 상호 작용할 수 있도록합니다. 적용이라고합니다. 전 APL 프로그래머에게이를 설명 할 때 비슷한 목표에 대해 유사한 조항이 APL에 존재한다고 나에게 말했다. Apply 절을 사용하면 테이블 행 또는 테이블 함수 행의 속성 집합을 다른 함수의 입력으로 전달할 수 있습니다. 즉, 함수로 간주되도록 작성하기 위해 테이블 함수 유형에 제한을가했습니다. 반드시 인라인으로 선언해야합니다. 즉, 단일 select 문으로 표현됩니다. 이것은 변수가 없다는 것을 의미합니다. 논리가 많은 이러한 쿼리를 작성하면 공통 테이블 식을 사용하여 식을 열로 변환 할 수 있습니다.이 식은 다른 CTE에서 재사용 할 수있는 변경 불가능한 변수입니다. 결국 함수는 매우 큰 매크로가되어 옵티마이 저가 필요한 방식을 자유롭게 최적화 할 수 있습니다. 사람들이 부족한 유일한 조건은 조건부 논리를 작성하고 쿼리에서 논리를 지원하는 일부 데이터를 선언하는 것입니다. 마지막으로 over 절을 사용하는 일부 함수는 다른 행의 행에서 사용할 수있는 값으로 결과를 전달하는 방법으로 필요하지만 여기서는 약간 긴 시간이 소요됩니다. 사람들이 부족한 유일한 것은 조건부 논리를 작성하고 쿼리에서 논리를 지원하는 일부 데이터를 선언하는 몇 가지 간단한 요령입니다. 마지막으로 over 절을 사용하는 일부 함수는 다른 행의 행에서 사용할 수있는 값으로 결과를 전달하는 방법으로 필요하지만 여기서는 약간 긴 시간이 소요됩니다. 사람들이 부족한 유일한 것은 조건부 논리를 작성하고 쿼리에서 논리를 지원하는 일부 데이터를 선언하는 몇 가지 간단한 요령입니다. 마지막으로 over 절을 사용하는 일부 함수는 다른 행의 행에서 사용할 수있는 값으로 결과를 전달하는 방법으로 필요하지만 여기서는 약간 긴 시간이 소요됩니다.