SQL yakalama

Göre Immerman ile ilişkili karmaşıklığı sınıfı , SQL sorgularını sınıfı tam olarak güvenli sorgu olarak , SQL yakalar güvenli sorgular: (birinci derece sorgular artı sayma) sayılabilir. (Başka bir deyişle, tüm SQL sorguları Q ( F O ( C O U N T ) ) ve Q ( F O ( C O U N $\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$ bir SQL sorgusu olarak ifade edilebilir.)

Bu sonuca dayanarak, teorik açıdan, verimli bir şekilde çözülebilen ancak SQL'de ifade edilemeyen birçok ilginç sorun vardır. Bu nedenle hala etkili olan bir SQL uzantısı ilginç görünüyor. Benim sorum budur:

Bir var mı SQL uzantısı (uygulanan ve sanayide kullanılan ) hangi yakalar $\mathsf{P}$ (yani tüm polinom zamanlı hesaplanabilir sorgular ve hiçbir diğerlerini ifade edebilir)?

Her üç koşulu da destekleyen bir veritabanı sorgu dili istiyorum. SQL'i genişletecek ve yakalayacak bir uzantı tanımlamak kolaydır $\mathsf{P}$. Ama sorularım böyle bir dil pratik açıdan mantıklıysa, pratikte kullanılan bir dil istiyorum. Durum böyle değilse ve böyle bir dil yoksa, o zaman böyle bir dili pratik açıdan ilgisiz kılan bir neden olup olmadığını bilmek isterim? Örneğin, pratikte ortaya çıkan sorgular genellikle böyle bir dile ihtiyaç duyulmayacak kadar basit midir?

Ana sorunuza gelince, Martin Grohe'nin bu kısa anketini öneriyorum .

Uygulamada ihtiyaç duyulan sorgular, daha güçlü bir dile ihtiyaç duyulmayacak kadar basit midir?

Genel sorgu dillerine eklenen eklenti miktarlarının (geçişli kapatma, aritmetik işleçler, sayma vb.) Göz önüne alındığında, bunun çoğu zaman geçerli olduğunu söyleyebilirim. Bu, nispeten basit web sitelerinin ve diğer uygulamaların serbest geliştiricisi olarak bazı çalışmalar yapan birinin bakış açısından geliyor, bu yüzden SQL'in daha büyük endüstrilerde / daha büyük veritabanlarında gerçek kullanımlarından emin değilim.

Nadir durumlarda daha güçlü bir dile ihtiyaç duyulabilir, tahminim yazılım geliştiricilerinin sorguları değil (C ++ veya java gibi) uygulamayı yazdıkları dili kullanarak onlarla başa çıkmalarıdır.

İlk olarak, SQL'in etkileyici gücü göründüğünden daha az kesindir. SQL'in toplam, gruplama ve aritmetik özelliklerinin oldukça ince etkileri olduğu ortaya çıktı. Bir a priori, bu özellikleri kullanan bazı cebirsel operatörleri kodlayarak, SQL'de gerçekten erişilebilirliği ifade edebilir. Bu aslında "yerel" olan SQL-92 için geçerli değil .

• Leonid Libkin. Etkileyici SQL gücü , TCS 296 (3), 379-404. doi: 10.1016 / S0304-3975 (02) 00736-3 ( ön baskı )

Bu, SQL-92'nin PTIME'yi yakalaması için bir uzantı gerektiği ve ortaya çıkan dilin "yerel olmayan" olmasına izin veren bir uzantı gerektiği anlamına gelir.

Bununla birlikte, sıralı yapılara izin vermek ve gerçekçi olarak sınırlı aritmetik ile, SQL-92'nin erişilebilirliği ifade edemediğini kanıtlamak, muntazam olduğunu ima edecektir ve bu nedenle oldukça zor olacaktır. (SQL-92'deki veri türlerinde her zaman doğal bir doğrusal sıralamanın olduğu ve bu nedenle temel yapıların sıralandığını varsayabileceği iddia edilebilir.)$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

SQL: 1999 (SQL3) özyinelemeyi içerdiğinden manzara yeniden değişti. SQL: 1999 en azından sayımla sabit nokta mantığı kadar etkileyici görünüyor (gerçi ayrıntılar sipariş konusu da dahil olmak üzere yine oldukça zor olabilir). Yeni yapıların mantığı PTIME'yi yakalamak için gerekenden daha etkileyici hale getirip getirmediğini bilmiyorum ve bunu oluşturmak için biraz çalışma yapılması gerekecek. Bu arada 2003 , 2006 , 2008 ve 2011 yıllarında başka revizyonlar yapılmıştır.(ISO belgeleri olduğundan, yalnızca taslaklar serbestçe kullanılabilir). Bu revizyonlar, XQuery'ye SQL sorgularının "parçası" olarak izin vermek de dahil olmak üzere bir dizi yeni özellik ekledi. Benim tahminim "SQL" artık PTIME yakalamak için gerekenden daha etkileyici, ama bunu yapmak için gereken kodlama gerçek sistemlerde desteklenmeyebilir büyük ve oldukça doğal olmayan sorguları gerektirebilir.

Bu nedenle , PTIME'yi tam olarak yakalayan ve sorunuzu bulanık bir şekilde cevaplayan endüstriyel bir SQL uzantısı olmadığına dair kanıt olduğunu düşünüyorum . Kısacası, endüstriyel genişletmeler oldukça güçlüdür ve PTIME'yi zaten aşmış olabilir. SQL: 1999'un en azından PTIME'yi yakalayacak kadar güçlü olduğu doğruysa, o zaman "SQL" in sorunuzda gerçekten ne anlama geldiği de açık değildir, çünkü biri SQL'den önceki bir sürüm anlamına gelen "SQL" tanımlamak zorunda kalacaktır: 1999.

$\text{P} \ne \text{NP}$

• Martin Grohe, PTIME'yi yakalayan bir mantık arayışı , LICS 2008, 267-271 . doi: 10.1109 / LICS.2008.11 ( ön baskı )

$P$$P$$P$$P$$P$

$P = NP$$P = NP$$P$$P$$NPC$

$P \ne NP$

$P = NP$

Muhtemelen gerçek amaçlar için mevcut değildir, kesinlikle vardır ve inşa edilebilir ve uygulanabilirdir. Bu dili, belirli bir sayıda adımda bir Turing makinesini simüle edebilecek bir şeyle tanımlayabilirsiniz. IE, bir P-complete problemini çözebilir. Ancak, böyle bir şey inşa ederseniz, SQL benzeri bir dilde sadece güvenli sorgularla sınırlamak için çok garip bir yol olan "sıra dışı sayıda adım verildi" kısıtlaması dışında neredeyse Turing tamamlandı. Adımlar bazı tabloların kayıtları ise bunu yapabilirsiniz, ancak bu hala pratik amaçlar için değerli bir şey görünmüyor.