프롤로그가 명령형 프로그래밍에서 SQL보다 덜 인기있는 이유에 대한 역사적 선례? [닫은]

12

선언적 작성 SQL은 명령형 프로그래밍 에서 매우 인기가있는 것 같습니다 . 그러나 Declarative 를 작성 Prolog하면 많은 복잡성을 줄일 수 있지만 이것은 그리 일반적이지 않습니다.

Prolog보다 SQL을 선호하는이 역사적 선례가 있습니까?

그 이유가 명령형 언어에 의한 기본 지원이 부족한 경우, 언어 작성자가 Prolog처음 에 기본적으로 지원하는 것이 왜 유용하지 않은지 대답 할 수 있습니까?

특정 예를 제공하려면 다음을 수행하십시오.

예제 1
대출 응용 프로그램을 평가하는 것은 몇 줄의 코드 만있는 쿼리 Prolog처럼 SELECT/JOIN몇 줄의 코드 SQL만있을 수 있지만 장점은 분명하지 않습니다 SQL.

예제 2
다음은 Prolog의 또 다른 예제 문제점 과 솔루션입니다. 다음 구속 조건 논리 프로그램은 교사로서 john의 역사에 대한 단순화 된 데이터 세트를 나타냅니다 .

teaches(john, hardware, T) :- 1990 ≤ T, T < 1999.
teaches(john, software, T) :- 1999 ≤ T, T < 2005.
teaches(john, logic, T) :- 2005 ≤ T, T ≤ 2012.
rank(john, instructor, T) :- 1990 ≤ T, T < 2010.
rank(john, professor, T) :- 2010 ≤ T, T < 2014.

다음 목표 절은 요한 모두 가르쳐 찾기 위해 데이터 집합을 쿼리 로직을 하고 있었다 교수 :

:- teaches(john, logic, T), rank(john, professor, T).

결과:

2010 ≤ T, T ≤ 2012.

위의 예 SQL에서 동일한 결과를 얻는 것이 쉽습니다 . 그러나이 데이터가에 있다고 가정합니다 Array. 그런 다음를 사용하여 동일한 결과를 얻는 것은 쉽지 않습니다 SQL. 그리고 배열에 저장된 데이터의 경우 Prolog 코드를 작성하고 유지 관리하기가 더 쉽다고 생각합니다.

— 53777A
소스

8

음란 한 부분을 다이얼 다운 할 수 있습니다.

4

대부분의 텍스트는 Prolog를 사용하지 않는 사람들에 대한 분노처럼 들립니다. 거기에 묻을만한 가치가있는 질문이 있지만, 다른 것들 (난간은)은 다운 보트를 끌어 들이고 답을 할 수있는 사람들을 끕니다. 다시 말해, 질문을보다 자선적인 방식으로 표현해 보는 것이 좋습니다.

6

"예를 들어 대출 응용 프로그램을 평가하는 것은 프롤로그에서 몇 줄의 코드 일 수 있습니다."나는이 응용 프로그램을 구매할 때와 같은 이유로 많은 사용자 정의 또는 생성 된 SQL 쿼리를 사용할 것입니다.

— Euphoric

7

어쩌면 나는 뭔가를 놓치고 있지만 여기에 대한 대답은 '사람들이 SQL을 사용하기 때문에 데이터베이스가 지원하는 것' 이라고 생각합니다 .

— GrandmasterB

3

그들은 어떻게 사용 프롤로그 ... 음 ... 사실은 ... 그들은 어떻게 사용 규칙 엔진 입니다, "임시, 프롤로그의 절반 비공식적으로 지정, 버그 쟁이, 슬로우 구현"을 .

— Jörg W Mittag

19

나는 이것이 주로 역사적인 것이라고 믿는다.

SQL은 주로 비즈니스 응용 프로그램을 만들기 위해 비즈니스에서 사용되었습니다. 일부 회사는 SQL 솔루션 판매에 활기를 불어 넣고 돈을 사용하여 SQL을 광고하고 많은 사람들의 마음에 밀어 넣었습니다. 이것은 특히 비즈니스 사람들에게 데이터가 얼마나 중요한지에 의해 강화되었습니다. 그렇기 때문에 SQL이 많은 경쟁 업체를 이겼으며 오늘날에도 널리 알려져 사용되고 있습니다.

다른 방법으로 프롤로그는 주로 인공 지능 분야에서 학문 분야에서 주로 알려져 있습니다. 학계 사람들은 비즈니스와 다른 방식으로 도구와 아이디어를 다른 사람에게 강요하지 않습니다. 일반적으로 일부 회사는 학계에서 태어난 기술을 일반 개발자들에게 전파하기 위해 광고해야합니다. 또한 데이터는 매우 중요하지만 "비즈니스 규칙"은 그렇지 않습니다. 중요한 것처럼 보이지만 데이터보다 훨씬 덜 중요합니다. 비즈니스 규칙은 일반적으로 쉽게 수정할 수 있습니다. "손상된"데이터를 수정하려고하면 일반적으로 훨씬 어려운 문제입니다. 따라서 비즈니스 규칙은 비즈니스 규칙 솔루션보다 데이터 솔루션을 얻는 데 훨씬 더 집중했습니다.

— 크게 기쁘게
소스

2

"일반적으로 일부 회사는 학계에서 태어난 기술을 일반 개발자들에게 전파하기 위해 광고해야합니다." 많은 좋은 아이디어가 학계에서 개발되었고 나중에 마케팅 능력이있는 회사들에게 인기가 있습니다. +1

— Giorgio

6

그 이유는 실제로 매우 간단합니다. 주어진 작업에 언어가 얼마나 유용한 지, 코드가 유지 관리 가능한지에 관한 모든 것과 관련이 없습니다.

SQL 문을 읽으면 많은 개발자가 언어를 몰라도 대부분의 기본 쿼리가 수행하는 작업을 결정할 수 있습니다. 복잡한 예제의 경우 시간이 더 어려울 수 있지만 기존 코드를 적용하거나 샘플을 처리하는 것은 비교적 쉽습니다. 이해의 장벽은 대다수의 쿼리에서 상당히 낮습니다.

몇 줄의 프롤로그를 읽으면 많은 개발자들이 약간 눈을 멀게하고 다른 사람을 위해 작업을 떠나고 아마도 거짓말을 할 것입니다. 프롤로그의 술어 구문은 쉽게 읽기에 적합하지 않습니다.

최신 정보:

코드 샘플을 기반으로 컬렉션을 구현하는 언어가 제대로 작동해야합니다. C # / Linq에서 솔루션을 구현했으며 프롤로그 샘플보다 크게 크지 않았습니다 (정적 타이핑 및 정의가 필요한 경우). 목록을 병합하여 단일 타임 라인을 검색하기위한 일부 임시 작업과 관련된 추가 단계가 있었지만 상당한 작업이 아니 었습니다.

— 제임스 스넬
소스

14

SQL이 COBOL 등급의 매우 상세한 "자연적인"구문을 사용하여 읽기 쉽도록 만드는 것은 사실입니다. 그러나 SQL을 모르는 사람이 몇 가지 join또는 count(*)그와 비슷한 것을 사용 하여 중간 복잡한 문을 올바르게 이해할 수 있을지 의문 입니다. 우리가 SQL의 기본을 이해한다면 그것은 때때로 그 언어를 사용해야하므로 이러한 기본을 배워야하기 때문입니다. 관계형 데이터 스토리지는 논리 시스템을 해결하는 것보다 훨씬 일반적인 요구이므로 Prolog를 배우는 데 필요한 강력한 요구는 없습니다.

— amon

3

@amon 그것은 좋은 답변의 시작처럼 들립니다 :-)

— svick

1

가독성으로 인해 SQL을 배우는 장벽이 낮아질 수 있으며, 프롤로그는 구문으로 인해 사람들을 막을 수 있습니다. 그러나 실제로 SQL 이해 하위 쿼리와 몇 가지 조인을 알지 못하면 사소한 것이 아닙니다. 그러나 간단한 쿼리로 시작할 때 낮은 장벽은 사람들이 Prolog 대신 SQL을 사용하여 시작하는 이유입니다. :)

— Dylan Meeus

4

@JamesSnell 죄송하지만 -1입니다. 귀하가 주장하는 내용이 RegEx 와 일치하지 않습니다 .

^(?:(?:(?:0?[13578]|1[02])(\/|-|\.)31)\1|(?:(?:0?[13-9]|1[0-2])(\/|-|\.)(?:29|30)\2))(?:(?:1[6-9]|[2-9]\d)?\d{2})$|^(?:0?2(\/|-|\.)29\3(?:(?:(?:1[6-9]|[2-9]\d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:(?:0?[1-9])|(?:1[0-2]))(\/|-|\.)(?:0?[1-9]|1\d|2[0-8])\4(?:(?:1[6-9]|[2-9]\d)?\d{2})$

.

— 53777A

1

@JamesSnell RegEx는 암호, 쓰기, 디버깅, 유지 관리 및 수정 또는 확장이 어렵지만 매우 인기가 있습니다. 당신이 옳다면 RegEx는 개발자와 언어 제작자 사이에서 현재 인기를 얻지 못했을 것입니다.

— 53777A

4

또 다른 이유가 있습니다. 실제로 SQL은 디스크에 유지되는 데이터에 유용합니다. 따라서 데이터베이스는 "긴"시간 (몇 달) 동안 데이터를 저장하는 데 사용됩니다. 모든 SQL 데이터베이스 (예 : PostgreSQL, MySQL, Oracle 등)는 디스크 (또는 SSD, 즉 제대로 전원이 꺼지면 데이터를 유지할 수있는 하드웨어)의 데이터를 관리합니다. 그러나 내가 알고있는 대부분의 Prolog 구현은 메모리에서 작동하고 있으며 데이터를 안정적으로 유지하는 데 사용할 수 없습니다 (정전 후에도 데이터가 지속적으로 유지됨). 그리고 SQL 구현은 테라 바이트의 데이터를 처리 할 수 있습니다 ....

물론 DBMS는 디스크에 즉시 쓰지는 않습니다 (나중에). 그러나 내가 들었던 프롤로그 통역사는 사실과 룰베이스를 디스크에 유지하기 위해 (암시 적으로) 쓰지 않습니다.

(일부 언어 구현에는 지속성 기능이 있습니다 (예 : SBCL with save-lisp-and-die...하지만 프롤로그는 수행하지 않습니다).

실제로 SQL은 디스크의 데이터베이스 용이지만 Prolog는 프로그래밍 언어 (텍스트 파일의 소스 코드 용)입니다.

— 바 실레 스타 인케 비치
소스

1

디스크 I / O와 엄격하게 작동하는 SQL 데이터베이스가 없기 때문에 매우 비효율적이며 (언제나 일부 메모리에는 데이터가 있음) 디스크에 프롤로그 제약 조건을 직렬화하는 데 기술적 장애가 없습니다. 지금 생각할 수 있습니다.

— idoby

3

이론적으로 말하면 SQL은 쿼리 언어이며 데이터가 관계형 모델로 설명되는 한 데이터 저장 방법에 대해서는 신경 쓰지 않습니다. SQL은 패러다임이 아닌 인터페이스 일뿐입니다. 비 지속적 메모리에서 순수하게 또는 부분적으로 작동하는 SQL 사용 데이터베이스가 있습니다. SQL을 사용하는 데이터베이스가 프롤로그 사실의 형태로 데이터를 저장할 수도 있습니다! [인용 필요] 결국, 사실은 단지 관계를 설명합니다. 반대로, Prolog 엔진은 모든 것을 메모리에로드하는 대신 사실을 디스크와 같은 방식으로 디스크에 저장할 수 있습니다.

— amon

1

이론적으로는 그렇습니다. 그러나 실제로 SQL은 디스크에 저장되고 있으며 이는 필수적입니다.

— Basile Starynkevitch

1

@BasileStarynkevitch 규칙 및 사실은 디스크에 유지되는 소스 코드로 작성됩니다. 왜 대신 데이터베이스에 저장 하시겠습니까? Prolog가 데이터를 유지할 수 없다는 것은 무엇을 의미합니까? 그렇게하지 않아야합니다. 이것이 데이터베이스가 존재하는 이유입니다. 좀 더 자세히 설명해 주시겠습니까?

— 53777A

1

정확히, SQL은 데이터베이스 용이고 Prolog는 프로그래밍 언어입니다. 그게 내 요점이야

— Basile Starynkevitch

1

지금까지 언급되지 않은 한 가지 측면은 1980 년대와 1990 년대의 "개방형"시스템에 대한 추진이다. 많은 곳에서 소프트웨어 공급 업체는 데이터베이스의 데이터에 산업 표준 액세스를 제공해야합니다. 당시 SQL은 잘 알려진 표준이었습니다. 프롤로그는 매우 난해하고 학문적이었습니다. 시스템을 쉽게 연결하기 위해 ODBC와 같은 인터페이스를 얻기 시작한 후에는 다른 기술에 관심이 없었습니다.

80 년대 후반에 시장 압력 / 조달 규정에 의해 SQL 인터페이스를 추가해야하는 ISAM 데이터베이스가 상당히 성공적인 곳에서 근무했습니다.

— 데이브
소스