SQL 캡처

Immerman 에 따르면 SQL 쿼리 와 관련된 복잡성 클래스 는 Q ( F O ( C O U N T ) ) 의 안전한 쿼리 클래스입니다 (일차 쿼리와 계산 연산자). SQL은 안전한 쿼리를 캡처합니다. (즉, 모든 SQL 쿼리의 복잡도가 Q ( F O ( C O U N T ) ) , 그리고 모든 문제 Q ( F O ( C O U N T를$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$ 는 SQL 쿼리로 표현 될 수 있습니다.)

이론적 관점에서이 결과를 바탕으로 효율적으로 해결할 수 있지만 SQL로 표현할 수없는 많은 흥미로운 문제가 있습니다. 따라서 여전히 효율적인 SQL 확장이 흥미로워 보입니다. 내 질문은 다음과 같습니다.

이 생길되어 SQL의 확장 (구현 및 업계에서 사용 )하는 캡처 $\mathsf{P}$ (즉, 모든 다항식 시간 계산 가능한 쿼리없이 다른 사람을 표현할 수)?

세 가지 조건을 모두 충족시키는 데이터베이스 쿼리 언어를 원합니다. SQL을 확장하고 를 캡처하는 확장을 쉽게 정의 할 수 $\mathsf{P}$있습니다. 그러나 내 질문은 그러한 언어가 실제적인 관점에서 의미가 있는지에 따라 실제로 사용되는 언어를 원합니다. 이것이 사실이 아니며 그러한 언어가 없다면, 그런 언어가 실제적인 관점에서 흥미가없는 이유가 있는지 알고 싶습니다. 예를 들어, 실제로 발생하는 쿼리는 일반적으로 그러한 언어가 필요 없을 정도로 간단합니까?

귀하의 주요 질문 에 대해서는 Martin Grohe의 짧은 설문 조사 를 권장합니다 .

실제로 필요한 쿼리는 일반적으로 더 강력한 언어가 필요하지 않을 정도로 간단합니까?

나는 일반적인 쿼리 언어 (전이 폐쇄, 산술 연산자, 계산 등)에 추가 된 상당한 양의 확장을 고려할 때 대부분의 시간을 유지한다고 말하고 싶습니다. 이것은 비교적 간단한 웹 사이트와 다른 응용 프로그램의 프리랜서 개발자로 일한 사람의 관점에서 비롯된 것이므로 더 큰 산업 / 대규모 데이터베이스에서 SQL의 실제 사용에 대해서는 확신하지 못합니다.

드문 경우지만 더 강력한 언어가 필요할 수 있습니다. 제 생각에는 소프트웨어 개발자가 쿼리가 아닌 응용 프로그램을 작성하는 언어 (C ++ 또는 java 등)를 사용하여 해당 언어를 처리하는 것입니다.

첫째, SQL의 표현력은 생각보다 명확하지 않습니다. SQL의 집계, 그룹화 및 산술 기능은 매우 미묘한 영향을 미칩니다. 우선, 이러한 기능을 사용하는 대수 연산자의 일부 인코딩으로 실제로 SQL에서 도달 가능성을 표현할 수있을 것 같습니다. 실제로 "local"인 SQL-92 의 경우는 그렇지 않습니다 .

• 레오 니드 리브 킨. SQL의 표현력 , TCS 296 (3), 379–404. doi : 10.1016 / S0304-3975 (02) 00736-3 ( 프리 프린트 )

이는 SQL-92가 PTIME을 캡처하기 위해 확장이 필요하고 결과 언어가 "로컬이 아닌"것을 허용하는 확장이 필요함을 의미합니다.

$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

그런 다음 SQL : 1999 (SQL3)에 재귀가 포함되었으므로 조경이 다시 변경되었습니다. 따라서 SQL : 1999는 계산을 통해 고정 소수점 논리만큼 표현력이있는 것처럼 보입니다 (순서 문제를 포함하여 세부 사항은 다시 까다로울 수 있습니다). 새로운 구조가 PTIME을 포착하는 데 필요한 것보다 논리를 더 표현 적으로 만들 었는지 여부는 모르겠습니다.이를 확인하기위한 연구가 필요합니다. 한편 2003 년 , 2006 년 , 2008 년 및 2011 년 에 추가 개정이 이루어졌습니다.(ISO 문서이므로 초안 만 자유롭게 사용할 수 있습니다). 이러한 수정 사항은 XQuery를 SQL 쿼리의 "부분"으로 허용하는 것을 포함하여 완전히 새로운 기능을 추가했습니다. 내 생각에 "SQL"은 PTIME을 캡처하는 데 필요한 것보다 표현력이 뛰어나지 만이를 위해서는 인코딩에 실제 시스템에서 지원되지 않는 크고 부 자연스러운 쿼리가 필요할 수 있습니다.

따라서 PTIME을 정확하게 캡처 하여 퍼지 방식으로 귀하의 질문에 대답 하는 SQL의 산업 확장이 없다는 증거가 있다고 생각 합니다 . 요컨대, 산업 확장은 다소 강력하며 이미 PTIME을 초과했을 수 있습니다. SQL : 1999가 적어도 PTIME을 캡처 할만큼 충분히 강력하다는 것이 사실이라면, SQL 이전의 버전을 의미하는 "SQL"을 정의해야하기 때문에 질문에서 "SQL"이 실제로 무엇을 의미하는지 명확하지 않습니다. 1999.

마지막으로, PTIME (Janoma에 의해 언급 된)을 포착하는 로직 검색에 대한 Grohe의 조사에 따르면, 언어의 일부로 선형 순서가 없으면 PTIME을 포착하는 것이 까다로울뿐만 아니라 그러한 로직이 없다는 증거도 의미 .$\text{P} \ne \text{NP}$

• 마틴 그로 헤 (Martin Grohe) , PTIME을 포착하는 논리에 대한 탐구 , LICS 2008, 267–271. doi : 10.1109 / LICS.2008.11 ( 프리 프린트 )

와 만 캡처하는 확장 프로그램을 원 하거나 와 외부의 항목 을 캡처하는 경우 질문이 명확하지 않습니다 . 안전한 쿼리를 원하고 그렇지 않으면 Turing-complete SQL 확장이 가능하기 때문에 정확한 클래스 에서만 흥미있는 것처럼 보입니다 .P P P $P$$P$$P$$P$$P$

인지는 모른다 . 경우 캡쳐 할 수있는, 다음 SQL 확장 단지 부울 식 다항식 시간에서 만족할 경우 계산 또는 다른 해결할 수 있어야 다항식 시간 문제.P = N P P P N P $P = NP$$P = NP$$P$$P$$NPC$

그러나 인 경우 지정된 부울 수식이 만족스러운 경우 SQL 확장 언어에서 계산할 수 없습니다.$P \ne NP$

부울 공식이 만족 스러운지 결정할 수있는 언어로 작성된 알고리즘 (또는 쿼리 등)이 있습니까? 나는 이것에 대답 할 수 없다 (그리고 아마도 라면 대답하고 있기 때문에 아무도 여기에서 할 수 없다 ). 이 질문은이 언어가 실제 목적으로 존재하는 것 같지 않다고 믿습니다.$P = NP$

실제 목적으로 존재하지는 않지만 반드시 존재하며 구성 가능하고 구현 가능합니다. 주어진 단수의 단계까지 튜링 머신을 시뮬레이션 할 수있는 언어로 해당 언어를 정의 할 수 있습니다. P- 완전 문제 를 해결할 수있는 IE . 그러나 이러한 것을 구성하면 SQL과 같은 언어에서는 안전한 쿼리로만 제한하는 매우 이상한 방법 인 "단일 단계 수"제한을 제외하고는 거의 Turing-complete입니다. 단계가 일부 테이블의 레코드 인 경우이 작업을 수행 할 수 있지만 여전히 실용적인 목적으로 유용한 것은 아닙니다.